Threat Modeling of Connected Cars using STRIDE

"Even discourse, even a poetic or oracular sentence, carries with it a system of rules for producing analogous things and thus an outline of methodology." -Jacques Derrida


The purpose of this article decomposes a methodical approach for applying the Microsoft STRIDE threat modeling framework to the Head Unit (HU) or infotainment system of a cyber-physical vehicle (CPV) in great fidelity. We will investigate the different types of threats and vulnerabilities inherent to HUs by studying a data flow diagram (DFD), taking a lack of security controls in mind, and how the presence of a vulnerability in a critical ingress point for communication, such as WiFi or GSM, can impact the integrity of the security of the entire system. The purpose of threat modeling is to consider the different risk treatment options for mitigating the threats and vulnerabilities discovered in the threat modeling process at the design stage of a HU.

The process of threat modeling is the act of identifying, enumerating, and prioritizing potential threats and vulnerabilities against a system to provide a systematic analysis of the probable attacker's profile, the likely attack vectors, and high value targets within the system.

Performing a threat model of a connected car's individual systems, such as the HU or TCU provides answers to three fundamental questions:

  1. What are the assets in the target system?

  2. Where within the system are the vulnerabilities?

  3. What are the most relevant threats and likely vulnerabilities to be exploited?

A head unit (HU) within a connected car, also referred to as an infotainment system, is the nerve center of both in-vehicle entertainment and administrative control of the features and capabilities of the automobile, such as controlling automatic rotation of door mirrors when the automobile is turned off or enabling/disabling features such as Bluetooth. The HU is therefore now critical to not just providing entertainment as old receiver's or in-dash stereos used to provide, but now enables the driver to administer the capabilities of the automobile; configure in-vehicle networking such as WiFi; and see in-vehicle warning data making it now a secondary instrumentation panel. While many head units offer differing functionalities depending on the make and model of the car (including the cost), they are separated by idiosyncratic differences in their technology stacks, from things such as the Operating System to the applications that run on top of it, including AndroidOS to other embedded operating systems, such as Nvidia Linux.

Unbeknownst to "Joe Public," head units are not actually manufactured by the automobile maker themselves. Instead, the automaker will put out an RFP (Request for Proposal) on the street for different manufacturers of HUs to bid on and ultimately build which is later installed into the car in the production line. Different HU manufacturers exist, such as HARMAN, now owned by Samsung; Continental AG, Aptiv PLC, and Denso, just to name a few.

Within the last 5-10 years, many of the RFPs from automakers now contain required sections in the Scope of Work for the OEM to perform penetration testing as well as risk assessments of the HU along with a report from the penetration testing firm at time of delivery with critical vulnerabilities already remediated. This has been a response from the industry to numerous critical vulnerabilities that have led to the compromise and remote control of CPVs through the telematics control unit (TCU) of the car that is connected to the HU. Three years ago, a vulnerability in a Jeep allowed researchers to take full control of the CPV from moving the steering wheel to controlling the brakes and acceleration.


Developed by Prarit Garg and Loren Kohnfelder at Microsoft in April of 1999 in a paper titled "The Threats to our Products," STRIDE is a mnemonic for the different types of vulnerabilities to a system under review: Spoofing, Tampering, Repudiability, Information Disclosure, Denial of Service, and Elevation of Privilege

While the impetus behind the conception of the STRIDE framework by Garg and Kohnfelder was originally to identify threats and vulnerabilities to software, it can easily be applied to perform threat modeling of CPV systems such as HUs and TCUs as I'll demonstrate in this article.

I will be attempting to dive as deep as I can into the threat modeling process using the STRIDE framework within the limitations of a blog post, but if you want to get a deeper dive, I cover this in much greater fidelity in my upcoming book, Hacking Connected Cars, Tactics Techniques and Procedures, which is available on Amazon or Barnes & Noble for preorder. The official book site is on my homepage at

Applying STRIDE

Our initial "shoot from the hip" reaction is to first start trying to find vulnerabilities in a system then quickly move to throwing money at the problem to try and buy security controls to treat those risks. But you can't protect what you don't know you have.

"You can't protect what you don't know you have."

In this article, we'll be performing threat modeling against a HU.

Create an Asset Register. Before you can understand the threats and vulnerabilities in the HU, you need to first understand what the assets are within the HU. This process is a decomposition of the system into its logical and structural components. The assets should include processes/elements of the system that communicate with each other internally within the system or assets that external elements communicate with or the internal elements communicates to. The asset register should also contain ingress points into the system processes running on the OS (Operating System), data stores, data flows, and trust boundaries. Effectively, what you're doing is mapping out all elements and what they communicate with.


  1. Radio Chipset

  2. Audio Amplifier

  3. WiFi Interface

  4. Bluetooth Interface

  5. DDR Memory

  6. Flash Memory

  7. Automotive Applications Processor

  8. System MCU

  9. Camera Input

  10. USB Interface

  11. SD Card Drive

  12. Color TFT LCD

Identify the threats. Next, you'll be creating a data flow diagram (DFD); an illustration of how data is processed, transmitted, and stored by a system in terms of inputs and outputs. A DFD has standard shapes to represent the different elements in a data flow diagram:

  1. EE: External Entity (E.g. Communication endpoints)

  2. P: Process (E.g. Function)

  3. DF: Data Flow (Transmission of data between two elements)

  4. DS: Data Storage (Storage of data, including databases, logs, data output, or files -- also includes trust boundaries)

The below table aligns each DFD element type to the STRIDE framework:

Figure 1: DFD element mapping to the STRIDE Framework (Khan, Rafiullah & Mclaughlin, Kieran & Laverty, David & Sezer, Sakir., 2017)

Having become popular in the 1970s in software development as first described by Larry Constantine and Ed Yourdon, DFDs were created for the visualization of software systems prior to the conception of UML diagrams. Specifically, a data flow diagram illustrates the transmission of data between two elements, termed as inputs and outputs. As its name implies, a DFD maps the transmission, processing, and storage of data between elements in a diagram.