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

[Paul] (00:07)

Welcome back, everybody, to Exploited: The Cyber Truth. I am Paul Ducklin, joined as usual by Joe Saunders, CEO and Founder of RunSafe Security. Hello, Joe.

[Joe] (00:20)

Hey, Paul, great to be here and I look forward to today’s discussion.

[Paul] (00:24)

Yes, automotive stuff. Which means that I need to introduce our special guest for this week, Sean McKeever. Sean is Global Product Cybersecurity Lead at Marelli. Hello Sean.

[Sean] (00:40)

Hi Joe, hi Paul, nice to be here.

[Paul] (00:42)

Great to have you. Now, our title this week is “When Vehicles Aren’t Just Machines.” I know, Sean, that lots of techies still refer to their computers as machines. They’d never dream of calling them PCs or laptops or Macs. But there’s a whole slew of other stuff in today’s cars, isn’t there? Right from engine management all the way to infotainment that keeps your children entertained in the backseat while you’re driving along. So how have today’s connected vehicles changed the game for things like privacy and cybersecurity?

[Sean] (01:22)

Even back 15 years ago, cars were still relatively analog devices, even though they had computers in them. They were mostly there to just keep the vehicle running and alert drivers if there were mechanical issues or possible failures.

[Paul] (01:36)

The notorious engine light.

[Sean] (01:39)

Right, check engine. Yes, it’s still there.

[Paul] (01:42)

Now they tell you where you are and where you want to go next.

[Sean] (01:46)

Yeah, I mean, they’re like 5,000-pound smartphones, really. They have sensors in most of the seats so they know whether somebody’s sitting there or not. Microphones, cameras, some internal, some external, 5,000-pound smartphones or tablets. They have all of that technology.

[Paul] (02:02)

And for our international listeners, those are pounds weight, not pounds sterling. So it’s not just aircon, it’s individual video screens, aircon separately for each passenger, and of course getting into and out of the car, starting it, and with autonomous vehicles, perhaps even driving it.

[Sean] (02:09)

Correct.

Yeah, and even without the autonomous part, they’re a lot more aware of what’s around them. Yes. They have blind spot monitoring, have automatic emergency braking if something unexpected shows up in front of the vehicle, automated lane keeping assist. So the vehicle will try and keep you between the lines. So a lot of monitoring and interaction with the driving of the vehicle that we didn’t have even 10 years ago.

[Paul] (02:51)

What should drivers’ expectations be around things like data stewardship and privacy and what happens to that data that gets collected whenever and wherever they’re driving?

[Sean] (03:03)

It’s a funny question because we seem to have just accepted that everything around us is keeping tabs on us. Smart refrigerator, how much milk I have. My microwave knows how long I cook my burrito. There have been several big privacy events over the last half decade or so where large amounts of data have been infiltrated from a credit monitoring service or what have you. The expectation is that the people we’re giving our data to will treat it safely and with respect.

[Paul] (03:08)

Yes.

[Sean] (03:31)

I don’t know that that has been proven out by the industry, not just in automotive, but in anything like the lawsuit against Google for tracking usage, even in incognito mode. So the expectation of privacy isn’t always met with the reality of privacy.

[Paul] (03:47)

Absolutely. I mean just look at ransomware attacks. These days they’re not only about scrambling files, they’re about stealing all your files first to put extra blackmail leverage on you. All of that stuff could be breached even if the intention of the automotive vendor was not to use it in a way that you would not expect.

[Sean] (04:09)

Well, it also comes down to what they are and what they are collecting. I can tell you that an always on constant monitoring, full telematics dump of everything the car does is very expensive. That’s a lot of data to pull off of a vehicle in real time and store. And I would say a good connected system architect will evaluate what they need and why they’re collecting that data. Because again, it’s expensive to collect and it’s expensive to store.

[Paul] (04:12)

Yes.

[Sean] (04:38)

If you make a million vehicles a year and you collect 24/7 telematics on all million of those vehicles, you’re not going to make any money on them by the end of that year. There is a trade off on what the companies are collecting versus what the expectation of what they could call.

[Paul] (04:55)

And do you think that if the primary reason why one or another automotive manufacturer might not be collecting the data is simply that their mobile telephony interface isn’t fast enough, that they might start collecting that data if suddenly high speed always-on connectivity becomes cheaper?

[Sean] (05:17)

It depends. I haven’t worked at every OEM. I haven’t worked at every tier one. Typically there’s a privacy officer involved who evaluates the data being collected and why that data is being collected. If there’s even a valid use case for it. It’s analogous maybe to like PCI certification for card processing. Yes. If you don’t have the data, you can’t have it breached. I have a fleet of work trucks.

[Paul] (05:40)

Absolutely.

[Sean] (05:44)

And I need to know when search intervals come up so I can effectively manage those. So it would be a valid data point to capture versus the need to know every time this thing is in operation, where it’s going, and all of that. If you’re doing logistics, that might make sense. But from fleet management, there’s specific data points that add value. But there are a lot of other data points that just add noise and also implications of having that data that could get lost or exposed.

[Paul] (06:11)

Sean, moving on a little bit, what about testing? Notably, the idea that in many cities of the world, automotive vendors have been authorised to do what is essentially alpha or beta testing of their self-driving software on public roads. How do you balance that in the real world?

[Sean] (06:32)

It’s an existential crisis in my brain. I don’t want to be on the street that has beta software driving a 5,000-pound smartphone. And we’ve seen a lot of anecdotes like self-driving cars stopping for Burger King signs thinking they’re stop signs.

[Paul] (06:40)

Yes.

I guess for some people they might be.

[Sean] (06:52)

But also if you think back 150 years ago when cars were first becoming a thing and how the laws were written to not frighten horses, I think some of it is just my own personal things moving faster than I’m comfortable with versus the reality of safety or not. I do know that there’s a whole safety discipline, safety engineering discipline around AISL ratings and such and that whether or not it’s an autonomous vehicle, that vehicle has to go through those.

[Paul] (07:22)

And there are different levels of autonomy, there? From, hey, we’ll hold the brake while you use the clutch on a hill so you can pull off easily, to why don’t you get in the back seat and have a nap and I’ll take you to Palo Alto. Right.

[Sean] (07:37)

And it’s that last bit that I think is the hardest bit. 90% of self-driving is probably pretty easy. It’s that 10% of that fire hydrant is blue instead of red. What does that mean? And the car is able to interpret that properly. I saw a video two or three weeks ago of a self-driving delivery robot, like a food robot, trying to cross the street while a fire truck was driving down and causing this whole incident where it stopped in the middle of the road because it heard a siren and now the truck has to stop because there’s a robot in the way and it not knowing where to go.

[Paul] (08:12)

I would have thought that argument would be solved by physics. Wosh!

[Sean] (08:15)

You would think, but also that if you run over a robot with a firetruck, now the firetruck might be stopped.

[Paul] (08:23)

Absolutely, yes.

[Sean] (08:25)

So the fire truck being driven by a human recognized, can’t run over this robot. The robot just froze and eventually did get out of the way. So it’s that 10% edge case of how quickly can these automated systems learn to react safely? And those outliers are the more dangerous ones. I don’t want to get into grisly stories, but there was a situation where a pedestrian was struck by a car that then knocked him into an autonomous vehicle and that vehicle’s safety system said that person was trapped under the car while it pulled over. Understanding how that can be handled in a way that doesn’t make situations worse.

[Paul] (09:04)

There’s a whole aspect around these matters of data collection, of public testing, and of just how innovative we want to allow automotive vendors to be. Now it’s my understanding that the interest and the attitudes of the regulators has been quite different between the United States and the European Union. Do you want to say something about that?

[Sean] (09:28)

So my purview is mostly in cybersecurity. I know there are different clean energy goals or that sort of thing, but the stuff I focus on is cybersecurity regulation and how to implement that. In the U.S., the regulations have focused on ISO standards, which are not prescriptive. They are more, this is how to establish and properly run a cybersecurity management program.

[Paul] (09:40)

Yes.

So that’s cybersecurity specific to the automotive industry rather than or as well as cybersecurity in general.

[Sean] (10:02)

So 21434 covers the establishment of a cybersecurity management program for automotive products, how to do threat and risk assessment, and how to track vulnerabilities in an automotive system. It prescribes you shall have a process to do this. It provides some examples, but it doesn’t say you have to mitigate every vehicle against cross-site scripting attacks, just to grab something random that doesn’t really happen.

So it is focused on the process of establishing cybersecurity for an automotive product, but not the specific implementation of how to reach that. In the EU with UNECE R155 and R156, they’re prescribing more of a vehicle type certification. The vehicle shall be resistant to these specific types of attacks and these specific behaviors.

R155 and 56 are very prescriptive to how the security shall be implemented. My concern is prescriptive security is not future proof.

[Paul] (11:13)

I hear you. You say, you must do these things, and then people go, okay, we will do only those things, and suddenly you’re in the whole world of checkbox certification. Right. Get the certificate, put it on your wall, minimum done.

[Sean] (11:29)

Yeah, if you remember the old days of password security, it must be eight characters and have a number and a capital letter. And what you wind up with is 800 passwords that are winter 2013, summer 2013. So they meet the letter of the regulation.

[Paul] (11:42)

Yes!

I see what you did there.

Interestingly, in the United States, NIST has in the past few years said, we don’t want those prescriptive regulations on passwords anymore. This thing about changing your password every 90 days. What’s the point of changing it if it hasn’t been compromised? Even worse, what’s the point of waiting 90 days to change it if it has been compromised? We need a better way. So how do you think these two different approaches will pan out.

[Sean] (12:18)

I think we’re going to see things continue to evolve. Unfortunately, we might wind up in a race condition with prescriptive standards, not meeting the reality of vulnerabilities on the ground. The automotive industry moves slower than most other technology spaces. If you look at how long it takes to bring a new laptop or phone to market, that’s typically a year, maybe two if it’s a whole new architecture of things.

Cars take five to seven years from concept to product rolling out to customers. So the reality is the standards we’re developing against today will be applied to products five to 10 years from now. And that’s the heartburn I have with prescriptive. It’s very hard to look 10 years into the future and say, yes, this is going to be the landscape we’re going to be competing against.

[Paul] (13:11)

Absolutely.

[Joe] (13:12)

And I, for one, am grateful that it takes a few years for these cars to be manufactured, precisely because there are safety considerations and of course cyber attacks put safety at jeopardy in some way. So striking that balance is key, but the problem for OEMs and suppliers, tier one suppliers and everybody else is that over time, there are multiple different compliance programs. 

In fact, in the United States, as we look at model year 2027 for connected vehicles, the country of origin of all your software components becomes a key thing. It becomes something that we do have to maintain and with good reason balancing that safety and that security along with any supply chain risk in general becomes a key aspect for product strategy in general. Fortunately for us, we don’t roll out cars in 30 or 60 or 90 days. It’s three, four, five, six years or what have you.

[Paul] (14:08)

And some of those rules in the US relate to countries such as Russia and China, don’t they? Does this mean that we might end up with a situation where, say, European cars that are imported into the US come with basically blank firmware and they just get imprinted with US-compliant firmware?

[Joe] (14:28)

I don’t think there’s that much gap between European and US markets. If you think about perhaps the China market where some cars are made in China for China, they might vary a bit more, but between Europe and US things are probably more consistent, even though some regulations will vary.

[Paul] (14:49)

Just to get a little bit funky now, to talk about criminality, Sean, I’d like to talk about basically gone in 60 seconds, good old fashioned car theft. The crooks aren’t managing to get a hot wire from the battery to the starter motor anymore. They’re actually using things like relay attacks using the legitimate digital key fob that’s in someone’s house to start the vehicle and drive off with no obvious signs if they get stopped that they’ve jury-rigged the vehicle in any way.

[Sean] (15:23)

There’s no broken window. There’s no damage.

[Paul] (15:26)

Exactly. There’s no screwdriver stuck into the ignition key. There isn’t even an ignition key, is there?

[Sean] (15:33)

In that particular example, no, there isn’t. From the vehicle’s perspective, it’s a completely legitimate use of the vehicle. It sees it as the key has been presented, I have opened the door, I have started the vehicle and the owner is driving. Commoditization of RF equipment with things like a Flipper Zero or a HackRF1 or just an SDR, a software-defined radio for $20 off of Amazon can do a whole lot of functionality very difficult to achieve 10 years ago.

[Paul] (16:03)

Yes, 10 or 20 years ago, special, what you might call, software-defined radios back in the day would have cost anywhere from $10,000 to $100,000 each, and they would have targeted perhaps one particular frequency band. These days, as you say, it’s a $20 digital TV chip repurposed. Is this a question of manufacturers lagging behind cybersecurity reality? Is this something that regulators should be concerned about given that when vehicles get stolen and joyridden they do pose a public risk? Or is it just something that it’s okay for them to say, we’ll let the insurance companies sort it out?

[Sean] (16:43)

I have personal opinions, and professional opinions. Professional opinion is that innovation in the space by non-automotive companies has outpaced the reality of the products they’re delivering. RF has been considered safe for over a decade for things like unlocking and remote starting vehicles. And I think that has been leaned on too heavily and perhaps a different solution is required. Unlike cellular or wireless computer communication, RF is easily listenable. It is very hard to take something as quick as a handoff between a fob and a car and encrypt that and protect it from eavesdropping because that transaction has to be so quick. If I introduce a key fob that requires you to stand next to your car for 90 seconds in a rainstorm, you’re not going to want to use it for very long while that encryption and handoff and multi-factor thing happens.

Evolution has to happen with that technology that we haven’t realized yet. It’s more than just making the RF encryption better. I think it needs more of a multi-factor process beyond just one fob, one car, and they work. And I think that’s what we’re missing.

[Paul] (17:59)

And sure, what do you think about the conflation, if that is the right word, or the inadvertent intersection in today’s vehicles between infotainment, car setup, and engine management?

[Sean] (18:16)

I feel like we’ve already had that trouble. The G-PAC was specifically an in-vehicle entertainment system, being able to bridge into a network that wasn’t entertainment and allowed remote manipulation of the vehicle. I feel like we’ve learned a lot from that, but at the same time, automotive products are commoditized to be inexpensive. So the less wiring, the less switches, the less stuff required to make a vehicle function, the easier it is to manufacture and the more profit that can be made on it. A power window switch panel from a 1985 Monte Carlo, you’ve got eight switches on the driver’s door, two on the passenger door. All of that wiring has to not only go to each door, but up to the driver’s door and then to the module under the dash to make all that work. Five to 10 pounds of wiring just to make windows go up and down.

[Paul] (18:50)

Indeed. 

You know, I saw on social media the other day a video of how the animated indicators, turn signals as you call them, on 1960s cars were, where they sort of pointed towards the direction you wanted to turn. And the complexity of it! There were dozens of wires and there was a little motor and there was a cam to make all the lights switch and you just think crikey 12 volt DC switches clicking away in a part of the car that could get wet.

What could possibly go right? These days it’s just a commodity chip, I guess, to do something like that. So I can understand why the industry wants to embrace that. Particularly if, like with electric windows, they’re not only cheaper and easier, they’re also popular because they’re cool and convenient. So how do we balance that functionality versus safety and security?

[Sean] (19:48)

Yeah.

Automotive networking is evolving. It was very stagnant for a very long time. The networks that vehicles used, CAN bus networking, was developed in the 1980s. If you were in computers in the 1980s and did any networking, that protocol looked very similar to you, to ethernet. It’s a broadcast protocol. Everything gets everything. There’s no intent of, I just want to talk to this one thing. No one else would hear me. That was very effective and very useful for a very long time in cars, but we’ve reached a point where that’s no longer the case.

So we’re seeing things like CAN FD, which is a flexible data rate and can do authenticated messaging and secure switch routing within the vehicle. Automotive Ethernet, which takes that even further. So we can isolate the networks to devices that need to talk and nothing else can hear.

[Paul] (20:54)

So it’s that sort of car type VLAN, if you like.

[Sean] (20:57)

Yes, yeah, very much so. So you have physical network subnets in the vehicle. This is safety, this is engine, this is IVI. But eventually there’s always some device that has to talk between those. So you have to firewall that. With the newer protocols, we’ll be able to have authenticated communication between the devices. So the ECU knows that it’s talking to the brake controller, not some kid with a laptop in the backseat. And it can encrypt that connection so that even if someone can get on that line, they can’t read in plain text what’s being said.

[Paul] (21:33)

So the theory is you could have a weekly secure infotainment system that maybe allows somebody to keep track of the movies your kids are watching or substitute content or do things that are obviously undesirable but in theory it should be very difficult for that to affect the operational safety of the vehicle at the same time. Is that right?

[Sean] (21:55)

Yes, and we’ve seen better delineation of those less safety focused systems. When we first started getting connectivity in vehicles, it was a one box. It was the radio and all of this. Now we’re seeing telematics move afterwards because that’s a secure thing that needs to be treated differently and may need to be replaced at some point. So we’re seeing controls that can be implemented in vehicles to prevent those less secure devices from interacting with safety critical systems.

[Paul] (22:25)

Joe, do you want to say something about how the supply chain comes into this? Because it seems that if your primary business is building great automobiles, and then you want to add on things like infotainment and driver controls and navigation and all that kind of stuff, then you’re probably going to be buying in the non-safety related components from all over the place. How do you keep track of that to make sure that you don’t introduce bugs that affect, say, safety parts of the car while you’re making things cooler for long journeys for the kids in the backseat.

[Joe] (23:03)

As you suggest with your question, Paul, there’s more and more consideration from a software perspective what the security requirements are in many of these components. There is a combination of different operating systems. There would be Linux based systems. There’d be real time operating systems, and there would even be Android based operating systems on these vehicles. And as a result of that, we have to be mindful of what the security posture is for not just the OEM itself, but all of its suppliers knowing what software is on all these software components helps that OEM and ultimately the consumer have more confidence that safety is front of mind and the security programs in place to meet expectations for driver safety and industry standards.

[Paul] (23:53)

Because it’s hard to give up conveniences that you’ve got used to, isn’t it? You not only love the feature, you expect it to work always and every time.

[Joe] (24:05)

Well, I do think also in going back to Sean’s point around the CAN bus being a standard that the automotive industry has benefited from since the eighties, there was a whole ecosystem built around the CAN bus and we all know the protocols and the messaging format. If we’re all used to that and we’re now introducing new components that might leverage different protocols and messaging and networking in general, there is not just innovation from the consumer’s experience, but innovation and adaptation from the supply chain itself and the software development practices. I agree with Sean, we don’t want to get overly prescriptive on these issues. At the same time, we want to make sure that as suppliers, we upgrade our software approaches and our security approaches.

[Paul] (24:54)

What does that say in respect of the nature of collaboration between, say, the automotive manufacturers, their suppliers, and importantly the regulators in the US and in Europe?

[Joe] (25:08)

There has to be a tight level of discussion, transparency, and a real deep understanding of the requirements. That’s true for security, but that’s true for product development in general. From a security perspective, the OEMs do want to know what the security risks are coming from their supply chain. There are things that can increase transparency, whether it’s a Software Bill of Materials or other means to meet expectations when an OEM publishes requirements.

I know Sean has many more examples than I could possibly have.

[Sean] (25:41)

The word there is collaboration. We seem to struggle with that globally, not just with automotive security, but in general collaboration, cooperation. That’s the hard bit. It’s not just between industry and regulation. It’s within the industry itself. The automotive industry is very focused on everything and is a special, unique problem. And we’re going to solve it this way in this and that way in that. So it’s not like computers where everybody uses WiFi with a specific standard 802.11g, because I’m old, and every computer can use that standard and talk the same way. If we look at CAN bus, every car since the mid 2000s has CAN bus in it, but every message is going to be different on every different car, even if they’re all from the same manufacturer. Automotive as an industry has prided itself on, we do it differently than everyone, even sometimes the same divisions within the same company.

We’ll do it differently. So that’s, I think, the evolutionary step that may need to happen, but also the industry may be resistant to do so because it’s very easy to make a car that gets 50 miles per gallon and can accelerate from zero to 60 in five seconds. What is the ownership experience of that vehicle that differentiates it from the market? And that’s what car manufacturers pride themselves on is that differentiation of what makes their vehicle special.

And so that’s baked into the DNA of building a car and is kind of the antithesis of collaboration. That’s the challenge we’re faced as an industry trying to find those collaboration points without losing what makes a specific vehicle special to the customer.

[Paul] (27:25)

So in other words, we still want strong competition, but maybe a little bit more of what I believe is loosely called co-opetition for the core things that matter around safety and security. So Joe and Sean, to finish up because I’m conscious of time, if we look ahead over the next, say, two to ten years, what emerging threats or trends in automotive cybersecurity or perhaps automotive cyber insecurity do you think that professionals in the industry should be most concerned about?

[Sean] (28:00)

I see probably there’s gonna be another privacy watershed event in connectivity in general, whether or not that’s automotive.

[Paul] (28:10)

Dear, yeah. You mean like the first very very massive ransomware attack and we all went dear. We knew this was coming, what a pity we waited till it happened.

[Sean] (28:21)

Yeah. And I don’t know that it’s going to be automotive-related necessarily, but I mean, we’re connecting everything everywhere. Yes. Somebody’s going to find that database that has everything correlated and dump it. And it comes back to what I said earlier about if you don’t collect the data, you don’t have it to lose. I think we need to invert our look at that. What do we need to know to make the thing work? Not collect everything and then run analytics on it to get the data we want.

[Paul] (28:38)

Man, yes.

[Sean] (28:50)

You know, my soapbox, if you look at a ring camera, it records all the time. And then in the back end, it decides what it wants and what it doesn’t. I’m probably overstating it. I’ve never worked on a ring camera. But if that camera is always recording and then we have a data center deciding, well, this is just flat content deleted. There’s nothing happening. Here’s somebody walking up to the door. Now we need to notify the owner of the house that someone’s in front of the house. Well, why do we have eight hours of content there that doesn’t do anything other than cars driving by and somebody gets access to that data they can figure out, the police patrol this block at this time. If that data doesn’t exist, then it can’t be stolen to do that thing. That, I think, is the paradigm that needs to be turned on.

[Paul] (29:25)

Correct.

So we may need to get into a bit of a less is more moment in the automotive industry.

[Sean] (29:38)

I guess what I’m on my soapbox, think over connectivity in general, collect the things you need to make the feature work. Don’t collect everything to make the feature.

[Joe] (29:48)

We clearly see that cars are connected software systems with wheels. As Sean says, iPhone with wheels. I envision more and more security built into the software systems from the first place with an eye towards exploit prevention. And even when patches are not available. We didn’t even get into over-the-air updates, but I believe that the software development processes need to reflect the state of the industry and certainly many of the companies are transforming their technical teams to be software teams already. And as a result of that, security practices incorporated into the software development practice shifts will come along with it. I envision secure development practices, transparency and supply chain with sharing vulnerabilities across the ecosystem, and certainly building security into the software development process in the first place.

In my mind, if you do that, plus think about segmenting all these components on the vehicles so they do not talk to each other since they don’t need to, the security posture of these automotive components and systems will dramatically improve over the coming years.

[Paul] (31:03)

I think that’s a fantastic way to end because you have come across very optimistically. We’re definitely not there yet, but it sounds as though there’s a significant movement inside the automotive industry to modernize in a way that says that we are on the right path. 

Sean and Joe, thank you so much for a fascinating discussion. I wish we could just carry on, then I wish we could have a subsidiary podcast show where we can talk about cool old cars.

That’s an interest of mine, if not a hobby anymore. But I think you’ve given some great insights both for automotive consumers and for automotive vendors, OEMs, and suppliers. So thank you so much for your passion, your insight, and your openness in talking about your personal opinions, not necessarily just your professional ones. So that is a wrap for this episode of Exploited: The Cyber Truth.

Thanks to everybody who tuned in and listened. If you find this podcast insightful, please don’t forget to subscribe so you know when each new episode drops. Please be sure to tell all your team about the podcast as well so they can listen in to Joe and Sean’s insights, experience, passion, and future-gazing. Once again, thanks to everybody who tuned in and listened. Remember, stay ahead of the threat. See you next time.