In my last blog, I discussed how vehicle-to-vehicle (V2V) technology could make our cars safer. Here, I’m looking at automotive threat modeling, a process that’s defined as a formalized way to identify potential security issues. The process is designed to highlight these issues early to increase the focus on security throughout design and development. While threat modeling has been used by some industries for years, the process hasn’t been well integrated into many automotive suppliers’ development process.

?

The threat-modeling process can be divided into five main steps:

At this point, it may be helpful to distinguish the difference between a threat and a vulnerability. A threat is what you are trying to protect against, while vulnerability is a weakness or gap that could potentially be exploited.

With automotive applications, the development team needs to consider more than just safety in their threat models. The connected car can be exploited for a number of purposes:

1. Vision – Begin by envisioning how the product (e.g., infotainment unit, braking system, tire pressure monitor, etc.) will be used and potentially abused.
2. Model – Create a model that describes the product’s functionality.
3. Identify threats – Use the model to identify potential threats to the product and the assets it protects.
4. Mitigate – For each threat, document existing mitigations and identify gaps.
5. Validate – Finally, validate the accuracy of the model, threats, and mitigations.

• Safety – How can attackers compromise the safety of the drivers, passengers and nearby people? For example, can an attacker manipulate communications between electronic control units to initiate a self-parking mode while the car is speeding down a highway?
• Privacy – How secure is the acquisition of driver activities data (e.g., location of vehicle, navigation destination, etc.)? A recent study showed that 5 percent of all Americans (or more than 15 million people) could be identified just by knowing their home and work zip codes.
• Fraud and theft – The connected car vision often includes the ability to easily make purchases from the car. How can developers protect your information from unauthorized commercial transactions? This area is a likely early target for attackers, as this exploit can be easily monetized.
• Mischief – How can you prevent interference with onboard non-safety vehicle systems such as infotainment, heating and air conditioning systems, etc.? While there’s no monetary gain to be had by attackers, developers still need to protect against the “bored teen” who wants to see if he can turn his neighbor’s heat up on the hottest summer day or continually honk the horn.

A use case or attack scenario describes a potential attack at a high level. Typically, use case development requires input from multiple sources familiar with the system. Scenarios deemed too improbable on their own may later provide substance for other more likely types of attacks. The elements of a typical use case are:

• Entry points – How an attacker may gain access to the vehicle systems.
• Access methods – The means that an attacker may use to access the entry points.
• Types – The type of attack that may be launched.
• Outcomes – The potential effects of the attack.

Real threat examples described here include an engine-halt air bag, a portable device injection, and a dealership download. First, the owner installs an after-market radio, which may come with an onboard malware that can access a vehicle data bus that could potentially mimic the air bag deployed message from the inflatable restraint sensing and diagnostic module to the ECM. The ECM reads the forged packet and shuts down the engine at highway speeds.

Next, the owner downloads music from an untrusted source and creates a CD. The file could contain malware that uses the infotainment unit to launch a denial-of-service type of attack against the electronic brake-control module.

Finally, the LAN at the service department gets compromised. When an automobile is connected to the dealer’s network via the OBD-II port during the process of providing service, the attacker could install malware that could be exploited later.

Then, you’ll need to determine which countermeasures should be implemented based on your risk responses and continually update the threat model as technology changes. In the automotive world, addressing these new vulnerabilities through software or hardware updates can be difficult to impossible in deployed vehicles. In the next blog, I’ll look at over-the-air firmware (OTA) updates to address this issue.

For the past two years, Gene Carter has been the Director of Product Management for the Embedded Security Business Unit at Security Innovation. Carter has spent the past 20 years in embedded and automotive product management roles for NXP Semiconductors, Philips Semiconductors, and Coto Technology. He holds an MBA from the University of Southern California’s Marshall School of Business and a BSc in Electrical Engineering from Tufts University.