"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
Background
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:
What are the assets in the target system?
Where within the system are the vulnerabilities?
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.
STRIDE
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 www.alissaknight.com
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.
Example:
Radio Chipset
Audio Amplifier
WiFi Interface
Bluetooth Interface
DDR Memory
Flash Memory
Automotive Applications Processor
System MCU
Camera Input
USB Interface
SD Card Drive
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:
EE: External Entity (E.g. Communication endpoints)
P: Process (E.g. Function)
DF: Data Flow (Transmission of data between two elements)
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.
In this step, you'll identify threats to the HU according to the STRIDE threats defined earlier for each component. But before doing so, you first need to decide on how that's done. There are two methodologies for performing STRIDE threat modeling:
STRIDE-per-element: This method of threat modeling is performed against each and every individual component making it a much more time consuming, exhaustive, and labrinthine. However, there are situations where a per-element model makes sense. It is however not effective in identifying threats that arise as a result of interaction between components. For example, a WiFi Evil Twin attack between an established wireless connection between the TCU and HU will only arise as a threat if there is a wireless network for communication and a previously established wireless session.
STRIDE-per-interaction: This type of model enumerates threats against interactions between components by considering the tuples (origin, destination, interaction) of the data in transit. This type of modeling is far less time consuming and exhaustive as it involves less components to be modeled. This type of model is ideal for cybersecurity threats since compromises typically involve communication between a source and destination.
Identify the Vulnerabilities. Next you'll identify the vulnerabilities in the individual assets documented in the first step. This would include both passive and active vulnerability analysis. An example of passive analysis is not sending any packets towards the destination system, rather, doing analysis online such as researching vendor advisories and open source vulnerability databases for the OS and applications running on the HU. For active analysis, you'd use port scanners, such as nmap, vulnerability scanners against any running services, or protocol fuzzers for custom written services created by the OEM (very common).
The vulnerabilities will then be classified according to the STRIDE methodology
Spoofing: An attacker tries to be something or someone he/she isn't;
Tampering: An attacker attempts to modify data that's exchanged between system components or component and user;
Repudiation: An attacker performs an action with the system or component that is not attributable;
Information Disclosure: An attacker is able to read the private data that the system is transmitting or storing; and
Denial of Service: An attacker can prevent the passengers or system components from accessing each other, such as affecting availability or normal operation of the system or vehicle.
Use Case
In this section I'll be performing an example threat model using STRIDE of a HU and TCU so you can see the principles I've described here put to practice.
Figure 2: Example DFD of HU + TCU
Figure 3: Example STRIDE Threat Model of HU + TCU
Summary
While multiple threat modeling frameworks exist, this article covered a common framework used in cyber-physical systems, STRIDE. In the next article in our series, we'll describe the idiosyncratic, unique features of the PASTA framework and how it can be used for performing threat modeling of a connected car.
While I did go into sufficient fidelity in this article to perform your own STRIDE threat modeling exercise against a CPV, more of this topic is covered in great detail in my upcoming book, Hacking Connected Cars: Tactics, Techniques, and Procedures along with sample templates that can be downloaded from the official book's web site.
As usual, if you liked this article, please support me by clicking LIKE and SHARE it to your own feed! This is the best possible way that you can support me and my continued development of new content. If anyone has anything to add or comment on in this article, please feel free to share it with everyone below in the comments section!
I am the Group CEO of Brier & Thorn, a Managed Security Service Provider (MSSP) and IT risk management consulting firm. I head up the Connected Car Division where my team and I perform penetration testing and risk assessments of cyber-physical vehicles (CPVs) for OEMs in the United States, Europe, and Asia. As a recognized thought leader in the new Internet of Everything economy, specifically telematics and infotainment systems, I can be found speaking at security conferences in North America and EMEA, podcasting, vlogging, blogging, and writing contributed articles on the idiosyncratic cybersecurity issues affecting IoT that matter most. Learn more about me at my homepage at www.alissaknight.com, LinkedIn, listen to my weekly podcast episodes, or follow me on Twitter @alissaknight.