Podcast: Software security and the connected car

Today the average new car has more lines of software code than has the Hubble Space Telescope, a Boeing 787 Dreamliner, and all the source code on your favorite social media app, Facebook, combined. And that’s just the beginning. In the not so distant future, your car will become no less than a mobile data center, capable of supporting a variety of new protocols.

The problem is up until now almost all of the software found within a typical car has been unintentional, created here and there over time, often to fill very specific needs. Maybe it was to control the airbags, or to monitor tire pressure, or to provide satellite radio, internet, and cellular service to the driver. Software in cars today was not put there as part of any grand scheme; it was much more a function of consumer demand for manufacturers to distinguish this year’s model from the previous. So do we secure this code – whether it is already in the car today, or will be part of it tomorrow?

You can listen to the podcast on SoundCloud or read the transcript below.

Vamosi: My guest this week is Chris Clark, Principal Security Engineer for Global Solutions, at Synopsys. He has been involved with a few automotive cybersecurity initiatives. I started the conversation by asking him about the current automotive landscape with respect to security.

chrisclark1Clark: Today is pretty challenging. The automotive industry is going through a lot of changes. When we look at the traditional automotive experience you have vehicle that is isolated, it is self-contained and odes everything that it needs to do from a safety perspective, from a functionality perspective, but now we’re looking at a connected world of vehicles and the influx of different types of connections that we’re seeing in those vehicle is proving to be challenging for the automotive groups that are out there, and they’re really taking a serious look at what are the challenges that we have already experience and what do we need to do to keep those from happening in the future. And it’s not just the tier 1 manufacturers like we talk about the larger manufacturers it is all the providers of the equipment that make up that vehicle and a lot of people don’t realize when we look at a vehicle, there’s more computing power in a car than in most computing environments from a historical perspectives. They’re ally taking a close look, making some good decisions, reaching out to the researchers and the security experts that are out there in the industry today and taking proactive steps.

Vamosi: But automobiles by and large have been a Tower of Babel where everyone contributes their own proprietary software. Would you say there’s also an awareness where they need to play well together and recognize what each other is doing?

Clark: Most definitely especially now that we’re looking at situations where vehicles have to communicate with each other. So when we look at the V2V market that is coming into play, it’s imperative that these Towers of Babel fall down and we start seeing these working group, I shouldn’t say working group, but more of an partnership between manufacturer and utilizing the standards that are there. When we look at a single vehicle today we have stuff like CAN0BUS, OBD-II, C, that allows the second tier manufacturers to provide an individual product to more than one manufacturer, and we’re just seeing that evolution grow when we go into that next step. So it’s definitely an issue that they that they are going to have to work together more closely.

Vamosi: So you just mentioned standards a moment ago. Are there some key standards that the industry is playing attention to and might there be a gap for the time being?
Clark: There is definitely a gap right now. When we look at security standards from a traditional IT perspective they really don’t fit in the vehicle perspective. There are some core components that make sense for both environments, but the reality is it is a very different type of situation. So when we talk about a vehicle and its security, it’s the vehicle and also the back end structure that make up some of these services that make these vehicles more appealing. There’s definitely a gap when it comes to how security is implemented in a vehicle and that is where some of the work that is being done at SAE comes into play.

Vamosi: Can you explain that further?

Clark: One of the challenges that was brought up to the forefront was the work that was done hacking the Chrysler vehicles. When that occurred it was kind of a wakeup call for the industry to say wait a second. We’ve taken security seriously, we understand that we need to look at what are the challenges from a vehicle perspective – but apparently that’s not enough. We need to dig a little bit deeper. When you really need to take a look at and find out what can we do from the standpoint of the industry to be more secure. And one of the first groups to step up was SAE in creating a working group to help define some of those challenges. That’s one of the working groups that is chaired by one of our own, which is Mike Ahmadi, in pushing the idea of how we apply the security challenges that we are experiencing.

Vamosi: Right now we hear about ISO 26262 and we hear about MISRA. How are those effective and what are some of the gaps that we might see in terms of security regarding those.

Clark: Well, they cover very different areas. From a MISRA perspective we’re looking at what is the software that is implemented, how is it developed, and how is it tracked over time. So we’re looking at a much deeper, more fundamental perspective. But when we talk about ISO 26262, specifically -12011, we’re looking at what are security practices. What are the measures that are being taken to ensure that whatever security requirement has been defined for a vehicle or a sub-command of a vehicle are actually applied so they look at different aspects of the entire development process. And this is where we start looking at the security practices that have been in the IT industry for quite some time. We look at the software development lifecycle. Traditionally when we looked at Automotive lifecycle the focus was vehicle safety and operational safety for that particular vehicle. Now we have to add this additional layer that says, okay, now are we not only looking at those safety components and assurance that the vehicle operates as intended, how do we make the software that is running on that vehicle more resilient. That’s where MISRA is going to come into play. When we look at the ISO standard 26262, that’s looking at more of a situation where we say we know that a vehicle may attack and what are some of the proactive features that we can apply to make it more resilient.

Vamosi: You mentioned SAE a moment ago, and they have standard, currently, but we are hearing about a new working group that is addressing a more specific aspect of that, can you explain the difference.

Clark: When we look at the work being done by SAE the working component that’s been recently defined is focusing on what are the different aspects of security that need to be considered so we don’t when we look at something that is more proscribed from a software development standpoint we have a very specific set of goals. But to get those goals we have to consider what precedes them and what types of attacks and all the other vectors that come into play from an attack perspective. And that’s where this working group is now is developing, in place now, is developing the standards and type of criteria that we’re going to want to look at from a vehicle perspective. And I should actually take a step back, not just from a vehicle perspective but all the ancillary services that can affect a vehicle as well.

Vamosi:So I take it that the industry is moving toward a degree of self-regulation, rather than waiting for various government entities to regulate them. Would that be a true statement?

Clark: That is definitely a true statement. When we look at the dichotomy between healthcare regulation and vehicle regulation, there are some similarities when you look at how is the software developed and what are the critical safety components. The main difference is that automotive industry, from a security perspective, has definitely jumped ahead of the curve, so we want to make sure that we’re addressing these issues before we have a regulatory body and in some ways it going to be more effective. There will be some regulation that will be out there. But comparing that to some of the other industries that are out there automotive is definitely taking a more pro-active stance.

Vamosi: This week Synopsys will be participating in Future Connected Car event in Santa Clara. Are there more of these events in your opinion than in previous years?

Clark: Definitely. When we look at the landscape, not just from automotive trade shows themselves but automotive shows focusing on security, it is much, much greater than in any previous year. I can think off the top of my head already ten trade shows that will be coming up in eight month’s span. Whereas in previous years we might have only two or three. And that just shows how serious the automotive industry is taking on these challenges.

Vamosi: When you think you can name ten off the top of your head, are these appealing more to the automotive side or these to the security side?
Clark: They’re definitely going to have an automotive slant to them or automotive focus but one of the key factors in most of these trade shows is now security. When we look at the different speakers that are coming into do these trade shows as well as the focus of the event, security isn’t one of the smaller portions, it is the major portion of the event and what they are actually advertising and promoting.

Vamosi: You mentioned the Jeep hack last summer. There have been other attacks on automotive software prior to that. What was different about the event last summer and the response you saw from the automotive industry about that?

Clark: I think the biggest thing is because security has become more prominent from a national perspective – from a worldwide perspective – there was a lot more news coverage of this particular event and what was compelling about the event, in my view, not only was it a discussion, there was an actual visual to what was occurring and that visual was actually taking place on roadways and that created some controversy but the reality is that type of event was needed to spur activity and that was not something that we would typically discuss in an open forum but it is out there. And what we saw out that was organizations starting to ask questions and relevant questions and a very short period after that event. The secondary to that is the manufacturer that got exposed in that particular event was aware of the vulnerabilities that existed and already had plans to release and patch these particular issues but they didn’t make it in time. That in and of itself was kind of an interesting revelation. As everything unfolded we found out okay this particular manufacturer understood the core issues but didn’t’ understand the criticality of it. A criticality of it from a knowledge or research perspective. Because the event was already out there they had to switch to more of a reactive nature where they could have been a little bit more proactive early on.

Vamosi: Earlier you mentioned the parallel with the medical industry. They had a similar public breach where a pace maker was attacked and what came out of that was an understanding that a lot of the medical device manufacturers did not necessarily have security teams in place. Are you finding that in the automotive experience is different and that they do have people in place and just mobilizing them?

Clark: That’s a double edged sword. The medical security community already had security practices in place and secure organizations but they weren’t as prominent. They didn’t have as much say in the overall product development or release of products. When the automotive industry every large manufacture we’ve interactive with and spoken with has a healthy security practice that is involved with multiple aspects of the development cycle of the vehicle and as well as the additional service and support of the vehicle. In that respect, even though connectivity happened as a later time from a vehicle perspective, it seems that they looked at what has happened in other industries, other verticals in history, and took ti seriously and started making those implementations early on. And because of the types of vulnerabilities we see out there, we can see that because it was an activity that started early on in the manufacturing and development process, that their security practices are much more richer and better implemented than what we see in medical practices in medical device manufacturers today.

Vamosi: Anything else I haven’t asked you that you’d like to bring up?

Clark: I think one of the things that’s important to bring up is when we look at the vehicles that are coming into the marketplace and see the capabilities and all the additional features of the car into the marketplace it is important that not only does the industry understand what the security implications are but the consumers of these vehicles have a better understanding what these implications are. When we look at connected vehicles we see the opportunities for this rich lifestyle, this enhancement of connectivity, but it can potentially come at a cost. People need to be aware that when we move forward with technology we need to drive that knowledge of what they are bringing into their environment as well.

Robert Vamosi

Posted by

Robert Vamosi

More from Automotive Cyber Security