BIS Research recently concluded an extensive and insightful webinar on the “Cybersecurity in Automotive | Connected Vehicles and Growing Security,” discussing the rising threat of cyber attacks and threats in modern automobiles integrated with AI technology, i.e., connected vehicles.
The webinar was hosted by Dhrubajyoti Narayan, Principal Analyst, Automotive, at BIS Research. He was joined by David Barzilai, co-founder and VP (Sales and Marketing) at Karamba Security, and Andrew Till, General Manager (Security Platform) at Trustonic.
Some very critical questions were raised during the session by the attendees, which were duly answered by the panel of speakers.
Here’s an excerpt from the QnA that took place during the webinar:
David – Today, the supply chain is rather like a pyramid shape, meaning that the vehicle manufacturer, or the OEM, buys electronic control units (ECU) such as the controllers, hardware, and software from tier one. So, if they have about 80 such ECUs in the vehicle, then they need to have enough suppliers to provide them. Tier 1 creates the hardware and the software, but they also buy from tier-2 modules of hardware and software.
These are to build that system to sell it to the OEM. With the software-defined vehicle, there is a flattening of that supply chain structure, meaning that the OEM buys hardware from tier one. The hardware, such as the microprocessors from NVIDIA and Qualcomm and hypervisor from another, and then they comprise the hardware kind of like backbone on it.
They buy software for multiple vendors in a flat way. So instead of buying the software as part of the system from tier one, now they have many tier-2 sorts of providers setting them directly. Also, the OEMs create software in hubs. So, in essence, you have the flat shape of OEM by hardware, software, software, and software like that. So this is about the first part of the question.
The second question was about the regulation. It means that the OEM now needs to impose cyber-security regulations on its entire flat-structured supply chain.
They need to show the OEMs that they met the regulation, so the OEM would be able to show that the entire vehicle type is now certified and secure.
Andrew – Yeah, the payments are an interesting area. We do a lot of work with different payment schemes, so one of the reasons for using hardware-backed security is to provide isolation from the Android world. For example, for payment schemes.
So, when you typically use a PIN entry system or a biometric authentication system for launching a payments app and verifying the transaction, you're loading secure drivers. So you're not reusing the same drivers and the same level of security that you're using when you're unlocking a phone.
For example, you're typically providing a lot of additional protection, which is why a little test you can do is if you open your banking app and you try and screenshot it, you won't be able to capture an image of the screen because the drivers are being loaded from the secure world and the Android or the Apple system can't see into that application and can't see what's in the foreground at that point in time.
So, a lot of good processes are already in place, and certification screens such as VISA-certified master card Schemes and EV Co certification that anyone providing a payment system should be validated, and in vehicles, that's no different.
When we think about reasons to attack a vehicle and to try and get hold of somebody's data, the instant you put payment credentials into a vehicle, what are they? Are they cloud-based schemes such as PayPal, or are you storing the credentials locally? We're making it more attractive to bad actors. So, you have to use the hardware-backed mechanisms, and you can also look at all of the other monitoring capabilities that the systems now support.
As David presented earlier, to detect if there's any malware sitting on the device trying to do things that it shouldn't do.
David – So, I'd like to add to what Andrew said. Indeed, as you can tell from Andrew's answer, the payment structure and system and the securing payment is a very mature market, and Trustonic definitely is a leader in that area to enable secure payment. Luckily, we can adopt those methods into the vehicle, especially with the software-defined vehicle where you have the idea.
The entire idea is to enable end users to upload or download applications and pay for them or features even and pay for them on demand. However, when it comes to the second part of that question, Android and open source, then this is much more kind of open.
As I said, wired market, because you have so many vulnerabilities, and now when you start dealing with safety and with vehicles that you utilize the open source and Android in general, there's a much greater exposure. Not only this, but the Chinese regulation required the OEMs to be accountable for the third-party applications that do use open source and Android and stuff like that. The biggest challenge over there from our point of view or those suppliers and the OEM is to ensure runtime integrity.
Some methods to solve them are very established and proven, but they must be deployed in order to overcome those new vulnerabilities as they are discovered in runtime or even known vulnerabilities that must not be exploited in order not to jeopardize user safety and privacy, and with that to violate the Chinese regulation.
Andrew – I would absolutely agree. I think that's going to be one of the big, fundamental changes of moving away from what David described earlier. As you know, looking at security component by component and then dealing with the integration challenge, when that normally results in having multiple different key injection systems in the factory, different test systems, different policy management, etc.
So, there's a cost of ownership driver that says the more you can standardize on a common vehicle security architecture you can take cost out of the back-end systems and the management, and there's also an element, a big part of the regulations are proactive active monitoring, proactive remediation of the issues and to do that when you are using a disparate or fragmented security environment is extremely challenging.
Hence, the regulations, I think, will absolutely drive it, from a level where we work, the hardware-backed security we, you know, we work on the vast majority of automotive silicon.
So, we can absolutely deliver a base foundational level of technology to tier ones and OEMs, and then I think we will see, and I'll let David perhaps elaborate on this.
I think we'll see a tighter, more strategic engagement with security providers.
So, it's not just a “Please respond to this RFQ.” It's “We are developing a new vehicle.
Please work with us to understand what state-of-the-art protection looks like and collaborate with us on the development of the requirements, etc.” So, it's again back to this concept of something being born secure. It's the first thing you start with, not the last thing.
David – So, ideally, indeed, secure by design is much easier to implement.
Unfortunately, we see that OEMs’ and suppliers’ take on security is kind of like, let's call it, well, the features first, security second. Therefore, they are much more challenged by the time to market and by how to design and implement the features.
Moreover, the question is how to be able to kind of like make the end product secure or secure enough to pass the regulation or through security, providers were brought in not at first, you know, right out of the gate, but rather tools, QA or you know, mid phases of development or even after everything is already done.
So for this, you need to have the agility of solutions; the ability to start by gap analysis provides me the documents of your architectural documents. Let's do a gap analysis. Let's see what the most radical issues that must be addressed now are, but the rest could be postponed with a good reason or the reason elegant way to apply software as part of the build or the CICD to protect the binaries as they are.
This enables us to still meet the cybersecurity regulations and the level of posture required, even if it's being adopted late to the gate and not from the design phases.
Then it would be, but in most cases, unfortunately, it's not the case.
David – It's a very good question, and you know, practically, it's tied to the latter part of my answer before. We have brought in late, and customers are under time pressure to meet the business plan; they need to meet the regulation, which is somewhat foreign to them. Their R&D is not so familiar with cybersecurity.
So the question is how to support your customers without interfering. They are in the processes and time to market, which is one. The second thing is how to create trust.
Because who am I? Kind of like, who am I to go and tell them what to do? Yes, we are cyber security experts, but they are their own product experts and subject matter experts. So, we have found that the pragmatic approach is the one that is best suited for customers’ needs and constraints and to our own ability to show value and build trust.
Meaning that we start with a small project, either pen-testing (penetration testing) a module of the ECU or doing Threat Analysis and Risk Assessment (TARA) project or gap analysis. They are very limited-time projects. The risk from the customers' point-of-view is minimal.
So, with that, we highlight the problems, and we also create trust, which enables us to sell and fulfill a greater need and a vaster area of our customers and enable them to meet the regulation without interfering with the time to market.
Watch the complete webinar below: