Exploited: The Cyber Truth, a podcast by RunSafe Security. 

[Paul] Welcome back, everybody, to Exploited: The Cyber Truth. I am Paul Ducklin joined by Joe Saunders, Founder and CEO at RunSafe Security. 

[Paul] Hello, Joe. 

[Joe] Hey, Paul. It’s great to be here. And as a Detroit guy, I am so excited for this podcast episode today. 

[Paul] Yes. In recent episodes, we’ve talked about OT, operational technology. So that might be pump rooms and canal lock gates and weather stations.

[Paul] Now we’re shifting gears literally and figuratively, and we’re talking about the automotive industry. So let me start off by asking you straight out, what makes today’s vehicles even more vulnerable than they were twenty, thirty years ago when this whole networkification of the automotive industry started with the CAN bus? 

[Joe] Yeah. Absolutely. I mean, the auto industry has obviously gone through a tremendous transformation over the past several years, and I would say in those early days with the CAN bus and diagnostics, those were just simple compute things that needed to be done in order to enable some functions on cars.

[Joe] But we’ve come a long way. There are now instead of computers on wheels, I think what we have is software systems that are driving cars altogether. With autonomous platforms, with self-driving vehicles, with all the different integrated components on a car, there are more than a hundred million lines of code in some cases on some vehicles. There can be forty, fifty, 60, 70, a hundred applications or different software components on a car, and there’s all sorts of connectivity, whether it’s radio or other means to communicate on a vehicle or between components on a vehicle, it just adds up to a lot more attack surface and certainly attack surface that has drawn the the attention of hackers. 

[Paul] And it’s certainly something that even if it wanted to, the automotive industry would be hard pressed to get rid of, isn’t it?

[Paul] I don’t own a car anymore, so when I need a vehicle, I go and hire one. And I’m always amazed. Before I set off, I think, right, what I’m going to do is check what’s left behind in the Bluetooth connectivity. It is amazing the sorts of tact that you see left behind by the past five, ten, 15 people who’ve used that vehicle over the last few weeks. And clearly, they wouldn’t be doing that if they didn’t think it was a vital part of modern driving.

[Paul] So even if we wanted to get rid of that, good luck trying. 

[Joe] Absolutely. And, you know, just getting directions and finding your way in a new city if you’re driving a car, obviously, that comes with a lot of convenience. And we used to have to sit down, map out our path, look at a map, and come up with maybe our handwritten notes where we’re gonna go. But, obviously, now today, so many cars display driving instructions.

[Joe] They connect to phones. They have access to information to help make that driving experience a better experience. But all that convenience and all that benefit to the consumer does come at a potential cost of greater exposure from cyberattack. And so just to paint the picture a little bit, in 2024, in terms of cyberattacks in the automotive industry, one big challenge is 92% of those cyberattacks occurred remotely. So that means that the communications over the Internet to gain access to vehicles is a go to move for attackers who wanna manipulate cars.

[Joe] 70% could affect software that is on millions of automobiles. 70% of those attacks in 2024. And finally, 35% of all the attacks in 2024 involved some kind of car system manipulation. So my point is there’s a lot of reason, despite all the adoption of the technology, to realize that we can’t avoid the cyber aspects that we enjoy on these self-driving cars or these software defined vehicles in general. 

[Paul] Yes.It’s amazing. I noticed that in the 1990s, car theft and the ability to start the car by cloning the key became very difficult. But suddenly, it’s the big thing, and there are no keys involved. These are people who are going online and buying for a very modest amount of money, automated kits that allow maybe two people, one holding a booster or an antenna to relay a signal, say, from a key fob inside the house, and someone who simply gets in the car and drives away as legitimate looking as you like. There’s no hot wiring. There’s no broken lock. Nothing’s damaged. As far as the vehicle is concerned, they got illegitimately. And if that’s happening with people who can go on and buy stuff for $50 and go and steal a car that’s worth a hundred thousand dollars just like that, one is probably forgiven for wondering how strong the security is in the rest of the vehicle, such as the brakes or the steering. 

[Joe] Absolutely.

[Joe] And that economic incentive is a real motivator for folks, and that’s what triggers part of it. And that’s why cybersecurity is so important. Imagine if you’re out buying groceries and you wanna get into your car, and you don’t wanna sit down all your groceries, maybe you have two bags in your hand, clicking something that opens the doors or opens the back latch to open it remotely is a very good benefit. But if those are the same means that allow someone to gain access in what appears to be a legitimate means and then find ways to start the car and drive away, well, you can see how, technically, that’s not a far stretch. We’re simply leveraging the protocols that are out there, and that’s the trick.

[Joe] There are standard protocols that operate cars that when a motivated attacker or hacker looks for a means to gain access, they can find it through all these connected devices on a car itself. 

[Paul] And it’s difficult to fix that compared to, say, pushing out an operating system update to a mobile phone or, as you’ve pointed out before, changing a web app so the next person who visits gets the new version. Because that protocol is already in use on millions of vehicles worldwide. So if you didn’t update that said, hey. Your current key isn’t secure enough.

[Paul] We’re not going to let it work, then you basically do a denial of service attack against everybody who’s already got a car. And so they end up locked out of their own vehicle and unable to use it. It’s almost like the cure could be worse than the disease. 

[Joe] Absolutely. And so there are best practices for ensuring that a car is safe and secure.

[Joe] There’s even protocols and standards for compliance, and so the solutions are well known. Of course, what it means, though, for the carmakers, it comes at an extra cost to make them as secure as possible, but they absolutely need to be safe. And so I think everyone agrees they wanna drive safe cars, not dangerous cars, and they want manufacturers to produce cars that are safe. It’s a good thing in my mind that it takes a car manufacturer three years or so to get a new model year out on the road because you do need to go through a bunch of testing, and you need to go through some good cyber hygiene and cyber practices in order to make sure those cars remain safe even though they’re connected and loaded with software. 

[Paul] Now, Joe, one standard that people may have heard of because it’s quite a well known number and it’s quite easy to remember is ISO 26262.

[Paul] And that’s not just an advisory thing for the automotive industry, is it? It’s a requirement that you comply with the relevant parts of it if you’re going to produce an automobile for sale. How does a framework like 26262 help in terms of both safety and security in both physically and the cyber world? 

[Joe] This gives you functional safety and standards for functional safety, is what 26262 does. What it offers you are things like functional safety practices, functional safety tools and methodologies, but also how to manage the different integrity levels for automotive safety, especially in autonomous driving and self driving situations.

[Joe] The ISO standard is a road map for car manufacturers to make sure they dramatically reduce the safety risk. And so, in some regards, that includes security standards that could affect safety. So I like to think about it as safety standards, and cybersecurity fits into the safety standard overall. 

[Paul] Yes. Because when you think about automotive safety with its sort of old school meaning, You probably think of somebody like Ralph Nader, and you think of seat belts, and crumple zones, and airbags, and all that kind of stuff.

[Paul] The physical security that stops us getting crushed or mangled. But when it comes to self driving cars or various levels of autonomy, then there’s as much or more danger from ill performing software, isn’t there? I know there are different levels of autonomy in so-called self-driving cars. You know, there are some that will help you do a hill start, so you don’t have to use the handbrake anymore. There are others which you can take your hands off the steering wheel, and others where you can basically get in the back seat and have a nap if you want.

[Paul] So how are those different levels and standards catered for in 26262? 

[Joe] The ASIL part of 26262, really gets to that, safety integrity level, and there’s four levels as you suggest. So A, B, C, and D. ASIL d is the most strict standard, and it’s really intended for those situations where you are in the back seat. It’s completely autonomous.

[Joe] But you can imagine there’s less restrictive versions of that if there’s things that involve driver assist or some sounds that might alert you that someone’s in your blind spot. And so you can imagine there’s different levels, and each of those has a different level of compliance towards safety. And the idea is if you’re going for the most grave situation that could put a passenger’s life at stake, you would want the highest level of safety, and that’s the idea of ASIL D. But if it’s really a convenience item that just kinda makes everyone’s life a little bit easier when driving a car or operating a car, but it doesn’t put anyone into a dangerous situation, then that’s closer to the ASIL A standard of certification. 

[Paul] So it’s like high school, but the other way around.

[Joe] Exactly right. 

[Paul] The A grade is the lowest grade, and D is the highest. 

[Joe] Yes. 

[Paul] If all it is is vehicle proximity or you’re reversing and you’re going to bump into your neighbor’s hedge, you could imagine that, well, why would we worry about that at all? But even for something like that, which is adviser or meant to be helpful, it is important that we have standards that say that if you are going to provide this sort of aid, then it should be more likely to be correct than to mislead you because, understandably, you will start to rely upon it.

[Paul] When you’re dealing with things like cameras and sensors, there’s an awful lot that can go wrong or that can change due to things like weather and lighting conditions. So this is a much harder problem to solve than it might at first seem. 

[Joe] Yeah. And I guess, a simple thing that everyone might be surprised by or take for granted is that a good example of, say, ASIL A, the least restrictive requirement, is something like the rear lights when you back up. It is an indicator that the car is going backwards.

[Joe] That is, something that you would wanna test for and always have happen. It doesn’t necessarily put the driver at risk, but it does help prevent potentially some damage or a car accident in some regard. With that said, the driver is still in full control. But as soon as you start to give control of the vehicle over to the machine as opposed to the driver, then there’s a lot more questions to answer and a lot more things to comply with. 

[Paul] Joe, we’ve talked about things that sound a bit more like conventional computer stuff.

[Paul] What about perhaps more complicated matters like ECUs, where this is actually controlling the engine and the braking systems and the actual functional parts of the car while it’s in motion? It’s not just saying, hey, there might be someone approaching from the left or right, or you haven’t got your lights on, I’ll turn them on for you. This is about actually making sure that when you press the middle pedal, your car actually slows down in the way you expect. How well protected are those not just against software mistakes, which will be bad enough, but against actual exploits and vulnerabilities? And for someone who builds such a device, if they’re a CISO of that organization, for example, what can they do to actually reduce the risk that these could be targeted not just by bugs that happen by mistake, but by malevolent outsiders with your worst interests at heart?

[Joe] So if you think about a car, you know, there’s definitely infotainment systems. There are autonomous driving systems and components, and then there’s the traditional vehicle operations. And if you think about the traditional vehicle operations, the braking system, something when the driver presses their foot on a brake, there is a signal that has to go from that press on the brake to the actual braking system to apply the brake itself, physically, you know, near the wheel and apply that brake. And so there is yet still messaging between those components, and that messaging operates over what’s called the CAN bus and the CAN bus protocol. And it’s really a messaging system that sends a signal from the brake pedal through the CAN bus all the way to the brake itself.

[Joe] And so you can imagine if that messaging somehow gets corrupted or manipulated, then you could start to change the vehicle operations, and that’s a very severe thing. And so if you have these different ways to unlock doors or turn on infotainment systems or engage other parts of the car through communications that are through sensors, then there are various points of entry on a car that allow somebody to gain access to, say, the CAN bus and then to manipulate that messaging. Now with that said, there could be other versions, supply chain vulnerabilities that might have some kind of backdoor into the component itself that could trigger some form of risk down the road. That’s much less common. The real common path here to think about is somebody going to do something to manipulate with the existing software that’s on the vehicle today.

[Paul] And we’ve talked about infotainment systems, and you imagine, well, that that’s just like my network at home. It’s a sort of separate thing. But my understanding is that although you have the sort of core control part of the network, I have turned the steering wheel to the left, the wheels are better follow suit. They’re not necessarily all separate networks, are they? They’re not physically separate networks.

[Paul] It’s a bit more like one network where the parts are kept apart by sort of software and firmware. A little bit like that guest Wi Fi channel that you have on your home router. You still only have one router and one internet connection. You’ve got to hope that your router is doing the job correctly because it is not two separate networks. It’s very much the same sort of thing for most cars, isn’t it?

[Joe] It’s very similar. And of course, as you design more and more modern cars, you wanna segment all these networks, as tightly as possible or as strictly as possible. But with all the communications and means to communicate on the vehicles with a well motivated attacker, they’ll find a way to jump from one network to the other. And that is in part the risk, is cars are connected, and they have many different components, even if they’re segmented slightly differently, but people still find ways to break through. And, unfortunately, the traditional protocol and networking through the CAN bus does feel like a bit of a dinosaur in the automotive industry, and, unfortunately, we can’t just get rid of it.

[Joe] It’s not easy to get rid of a key aspect of how vehicles operate. There’s a whole ecosystem built around it. All the components that are on cars are used to communicating through a certain way. So you really have to redesign the cars, networking and components and messaging and standards of communication across the board in a comprehensive way. And that requires certainly good software architects and security architects to redesign cars, let alone proper communications engineers and networking engineers to get that right.

[Joe] Today, it’s been very, very hard to break away from the traditional CAN bus ecosystem, and it’s for a couple different reasons. The ecosystem’s already built around it. A lot of the parts, everyone already complies. And as you and I have talked about in the past, getting access to diagnostic information is something that the automotive industry needs to do. You can’t just control all the service repair shops yourselves.

[Joe] There are independent service providers who need to be able to get access to the information to fix cars. And so there’s a need to be open and to share data about diagnostics, and there’s a need to protect systems when they’re running. 

[Paul] So, Joe, it sounds as though there are two things that we’ve spoken about several times before that are even more important in the automotive industry than they might be in, say, the pump room industry. And those are Secure by Design and supply chain control, know thy supply chain, Software Bills of Materials. But the automotive industry is notorious for having an enormous supply chain.

[Paul] It’s not just the fact that the moving parts in the car may come from dozens, hundreds of different sources. With all these different levels and types of software and protocol histories, it’s much more complicated than a typical IT programmer probably realizes, isn’t it? 

[Joe] It is very complex. I mean, I think it’s fascinating. I think that it’s an engineering marvel that these cars work the way they do and that the software and the data that supports it, works so well.

[Joe] It’s simply amazing. And yet, if the supply chain is complex, if you source products that are fraudulent, if you source products that you know, there are restrictions in The United States. If you sell a car today in The United States, there are restrictions on where you can get some of those parts. You can’t get them from China. You can’t get them from Russia.

[Joe] And so how do you know that a software component is not built by an entity from one of those countries, and how do you know that you comply? So there’s even complex investigation or determination that you need to do in your supply chain in order to ensure that the parts that you source for your car don’t come with software from some of these, restricted countries. Imagine this, though, the LiDAR that detects all the components to help enable the self-driving cars. It used to be many of those LiDAR components came from China. And you can see how if all that data about where cars are going and what they see is out there, if those are defense oriented vehicles or state department vehicles, you can see how that information could be used by a foreign adversary of some sort.

[Joe] And so there are a lot of complex issues and there’s nation states involved in the supply chain, and it may make things harder before it gets easier. 

[Paul] So if you’re an automotive development team and you’re just getting started on Secure by Design, maybe you’ve decided it’s important to be seen to sign the pledge as we’ve talked about before. What are the first two or three things that you think a company should do if they want to improve their software development life cycle, particularly in the context of the complicated and strongly regulated automotive industry? 

[Joe] I think there’s a couple things. First of all, there’s some common operating systems that are used in vehicles.

[Joe] So from BlackBerry, QNX is on 250,000,000 cars, and that’s a real time operating systems that used in different ways. Linux and embedded well, I should say embedded Linux is also used commonly in infotainment systems as part of it. And then there’s also Android devices that are part of that infotainment system. And so really knowing the state of security for those keys, the real time operating system, the embedded Linux, and Android is one critical aspect for automotive security. The second one then is to look at the common framework for interfaces, because what that means is it really gives the OEMs and others the ability to really know that they’re not going to go too far afield when working with a new provider.

[Joe] Ultimately, on the software development process itself, having automated build tools, test tools, and ways to really ensure that what you build is in compliance with the 26262  safety standards and the autonomous driving standards, you know, as published through ASIL as part of that 26262  standard. Those best practices all have to come to bear. So the automated testing, build tools, testing tools, and ensuring that you have the compliance artifacts for all the safety standards, I think, is probably the final area that any developer in the automotive industry needs to adhere to. 

[Paul] And the jargon term amongst developers is shifting left, isn’t it? I’ve never quite liked that term because I always found it a bit confusing.

[Paul] It imagines that you have graphs, you have the earliest dates on the left and the later dates on the right. And the idea is basically, start as early as possible. Don’t wait until it’s too late and you’re just scrabbling to pass the tests and to get the check boxes done. Do it from the beginning so that while you’re developing, relevant tests and relevant test passes are coming along with you. You don’t have to go back and change a whole load of things in the future to pass those tests.

[Paul] Because when you change things to pass the test you need to pass now, you invariably introduce new bugs that you don’t know how to test for yet. 

[Joe] Exactly right. So it’s far easier to add in security, for example, as you’re building something than to find out you have a big exposure, big vulnerability, and then go back and fix everything retroactively. The last thing you want to do is have a cybersecurity safety recall and fix bugs that are putting drivers at risk. It’s much easier to fix them upfront, and so shifting left to delivery, to the build side, to the source code side, adding in security as you go is a much more efficient and economical way to solve the problem.

[Paul] Joe, let’s then finish up by giving you the chance to answer a question to which I assume the answer is kind of obvious, but nevertheless worth saying. If you’re building automotive systems and you get Secure by Design right, what are the major things that will benefit consumers, the industry, and the community?

[Joe] I think the biggest thing is, elevating the safety compliance of, you know, some of these benefits that are added to cars. So if you think about autonomous driving, you think about the infotainment systems, if we’re able to deliver more and more value to consumers in these software defined vehicles, then consumers win. But if we can do that in a really safe way and in compliance with the strictest safety standards, then society benefits.

[Joe] Having a safe, secure, efficient, convenient car that really does everything for you and you can, you know, relax a little bit, then everybody wins. 

[Paul] Yes. If safety and security really are part of the value of what you’re buying, not merely just some kind of cost to be minimized. 

[Joe] Well said. 

[Paul]  Joe, it’s clear that you feel very passionately about this, but you’re also able to talk about it in a very unemotional way to try and get everything right.

[Paul]  I really would like to thank you for that. And I would also like to thank everybody who tuned in and listened. That’s a wrap for this episode of Exploite: The Cyber Truth. If you found this podcast insightful, please be sure to subscribe and share it with your team. And remember everybody, stay ahead of the threat.

[Paul] See you next time.