A Strategic Approach to Automotive Security

In recent years, we have witnessed many technological advancements in the automotive industry. From advanced driver assistance systems to connected mobile apps and digital keys, this technology brings convenience to our lives, but with it a new set of risks.  

In an industry where a single mistake can put lives on the line, it’s pertinent that we take a strategic approach to automotive cybersecurity to ensure the functional safety of each vehicle, and related systems and applications, before malicious actors can cause harm. 

Standards such as the ISO 26262-1:2018 and ISO/SAE 21434 were specifically designed to address functional safety and threats to automotive security. For example, the ISO/SAE 21434 features the Threat Assessment and Risk Analysis (TARA). TARA breaks down threats in a system so engineers can calculate the risk of any one component to the entire system and mitigate those threats in the design phase.  

Even so, the technological design of a standard car contains multiple electronic control units (ECUs), with some luxury models containing well over a hundred. Each of these systems could contain more than 100 million lines of code, especially systems that deal with the outside world such as Automotive Head Units (AHU) or Telemetric Boxes (T-BOX).  

Every access point and added feature in the design makes it more difficult to identify vulnerabilities and serves as a potential vector for bad actors. So, what can original equipment manufacturers (OEMs), suppliers, vendors, and others do to strengthen their security efforts to keep pace with innovation? 

In this blog, I will discuss emerging automotive security risks and break down four automotive security best practices to help you improve your cybersecurity programs. 

Five Automotive Security Risks 

Misconfiguration in Automotive Software 

Most ECUs run on some form of operating system. The device may run QNX, a modified version of Android, or another specialized Real Time Operating System. Some of the ECUs found in today’s complex automotive systems require the full processing power of an operating system. Gone are the days where all of the automotive systems in the vehicle run bare metal code on weak processors.  

However, with every added feature, parsed protocol, or secure bootloader configuration, there is a chance for some misconfiguration or coding error to bypass development teams. This condition is especially true with software that interacts with the user or the outside world.  

The software for any installable applications such as a USB, Bluetooth driver, or even the Digital Audio Broadcasting (DAB) data that shows song information on the radio can, and has, allowed for aspects of the vehicle’s systems to crash or become compromised. This is more important the closer the Controller Area Network (CAN) bus or other diagnostic protocol segment is to the telematics unit because that allows the attacker potential access to the system over a range of wireless media.  

Attack on Automotive Hardware 

The automotive hardware that makes up a vehicle not only consists of the ECUs but also the sensors and the Hardware Security Modules (HSM). All these devices, including those that are added to increase the security of the vehicle contribute to the attack surface area of the car. An attack surface includes any system that an attacker with physical/remote access to could attack, extract, meddle, or spoof to explore a vulnerable system in the automobile.   

One area that is often a concern is how the system handles sensitive information at rest. There are a few ways to stop an attacker from extracting the non-volatile memory from an AHU and dumping/modifying the file system if it has not been encrypted and signed. Furthermore, self-driving autonomous vehicles are only as safe as their sensors are reliable.  

If an attacker extracts information from an HSM, spoof a sensor, glitch a debug port, or compromise the integrity of any part of the system, they could take any action. In automotive security, this threat is even more imminent because the architectural secrets gained on one vehicle could lead to the attacks of many (i.e., an entire fleet). Extracted firmware keys, Joint Test Action Group passwords, and network access to other cars are only some of the attacks that could be managed. 

Unauthorized Access in Debugging Ports 

Debugging ports are serial ports that are active during the development of a piece of hardware and software and then terminated when the system goes to production. This is not the case in automotive.  The data must be retrievable in case there is a failure in the device so that the root cause can be addressed.  

These interfaces should still be protected via a password key that restricts access to the device, unpopulated header locations, or software configuration. However, they won’t prevent attackers from attempting to access them. If attackers gain access to these interfaces, they could gain developer-level access to the device with the ability to implement their own malicious “features” into the ECU. 

Breach Points in the Network 

Automotive systems have several networks today. Where we used to have only the CAN Bus, which is still used today, we now use FlexRay, LIN, DoCAN, DoIP, and several others – each with their method of transmitting data and diagnostics.  

While these networks should be segmented, there are still breach points. We have developed some encryption methodologies to prevent an attacker from gaining access to a device that could breach other devices. This is accomplished by adding a layer of complication to the processing of the network traffic, especially when considering repaired or aftermarket parts and new key exchanges.  

Containers  

ECUs control the electronic functions of a car and now incorporate their own operating systems, but this is just the first step. More advanced ECUs have their own containers, which allows for a quicker development time and added layer of protection.  

Some of these containers are typically used for machine learning implementations to perform autonomous or assisted driving features that are prominent in many modern cars – a potential focus of attackers in recent years. Containers are normally thought of to be somewhat secure, but every year there are more reports of how these systems are misconfigured. They can be modified and, in some cases, used to perform privilege escalation. 

Four Automotive Security Best Practices 

Let’s dive into automotive security best practices and what you can do to improve the overall program security of your automotive. Here are four best practices for you to consider. 

Familiarize Yourself with the Automotive Threat Analysis and Risk Assessment Method (TARA)  

ISO standards, also known as the International Organization for Standardization, is a set of standards internationally agreed upon by experts. These processes range in types of activities and need to be addressed multiple times through the product lifecycle.  

TARA specifically recommends several threat modeling methods that can apply to automotives: EVITA, TVRA, OCTAVE, the HEAVENS security model, Attack trees, and SW to name a few. You can find more info in ISO 21434, but note that these are only recommendations – and the methodologies are adaptable. Other methodologies exist to check for automotive security, but no matter which method you use, make sure it provides good coverage and documentation of the areas where there are automotive security concerns. 

Review Code at Standard Intervals During Code Review to Reduce Errors 

Engineers don’t like to spend longer than necessary in a secure code review as most programmers produce code more than they enjoy reading it. However, reviewing code at standard intervals reduces the number of errors that show up in the production systems. Additionally, it may be beneficial to employ some form of automation to discover more hidden errors. 

Incorporate Fuzz Testing in the Quality Assurance Process 

Fuzz testing is a strategy for discovering bugs that other software testing methodologies can’t. Due to the speed and sophistication of input mutators, this brute-force method of bug hunting can be effective at finding flaws in network protocols, file handlers, and similar data. While it takes time to create fuzzing software to suit the needs of the system, if done right, that investment will save more time in the long run. 

Check Your Cellular Connections 

There are a few areas where traditional networks and automotive systems intercept. Where these intercepts exist, ensure at every possible configuration that the system is fuzzed. One often overlooked area is the use of a cellular test station to connect to the automotive T-BOX. This is important because, under normal circumstances, telecoms tend to act as makeshift firewalls for mobile devices. But you can’t always depend on them, especially when attackers can create their own cellular test systems.  

The Importance of Automotive Penetrating Testing  

It takes skills to design and implement the features in our vehicles today. Engineers have a certain method of thinking about problems and rarely think maliciously about the devices they are working on.  

They may know areas where effort has been lacking or bypasses that may not be covered in detail in the architecture diagram. When it comes to knowing the best way of combining these issues into a chained attack, engineers and quality assessment personnel fall short. It is one thing to know where a flaw is, but another to understand how to apply the correct pressure to the flaw and determine the true strength or vulnerability of the vehicle. 

In addition, the technologies and techniques used in attacking systems change faster than the technologies they attack. Keeping up to date with the newest attack methodologies requires a person’s full-time attention.  

That is why I find it is typically better to have a group of experts already dedicated to keeping abreast of the newest methodology and who developed their own tools to evaluate your unique automotive security requirements. You can invest in your own penetration testing teams or seek out penetration testing services, like NetSPI’s automotive pentesting. 

Automotive environments are complex cyber-physical systems, but there are many opportunities to improve your security maturity. This blog and the automotive cybersecurity best practices shared within are just scratching the surface of this unique threat landscape. If you’d like to continue the conversation with me and dig deeper, don’t hesitate to reach out at www.netspi.com/contact-us.