Securing the Car : How Intrusive Manufacturer-Supplier Approaches Can Reduce Cybersecurity Vulnerabilities

The modern car is increasingly dependent on electrical and software systems. A modern vehicle has anywhere from 30 to 70 electronic control units that monitor and control its different subsystems (Studnia et al., 2013a), which are integrated using "glue code" (Checkoway et al., 2011). The glue code enables car manufacturers to outsource the development of particular systems and subsystems, which are then integrated when the car is assembled.


Introduction
The modern car is increasingly dependent on electrical and software systems.A modern vehicle has anywhere from 30 to 70 electronic control units that monitor and control its different subsystems (Studnia et al., 2013a), which are integrated using "glue code" (Checkoway et al., 2011).The glue code enables car manufacturers to outsource the development of particular systems and subsystems, which are then integrated when the car is assembled.
However, within and between these modules, several cybersecurity vulnerabilities in the modern car have been identified and documented by researchers.Examples include vulnerabilities in sound systems, Bluetooth modules, onboard diagnostics systems, cellular communications, and the bus connecting electronic control units, (Checkoway et al., 2011;Eichler, 2007;Hoppe et al., 2009;Koscher et al., 2010;Raya & Hubaux, 2007;Wolf et al., 2004).Practitioners have also stressed how vulnerable the modern car is to cyber-attacks (Miller & Valasek, 2013;Venturebeat, 2013;Yadron, 2014).Both local and remote attacks have been documented (Studnia et al., 2013a).Theft, electronic tuning, sabotage, and surveillance are among the goals of those who cyber-attack cars (Studnia et al., 2013a).Most vulnerabilities in the modern car arise from incorrect assumptions made by the glue code that calls functions on different electronic control units (Checkoway et al., 2011).These incorrect assumptions may occur at the subcomponent level as well as the interface level.Checkoway and colleagues (2011) argue that the true source of the glue code problem can be traced back to the setup of the ecosystems used to manufacture cars.Auto manufacturers build ecosystems to outsource digital systems in the same way that they outsource mechanical parts.Although every supplier tests their modules, security vulnerabilities usually arise when those modules are subsequently integrated by the car manufacturers.Outsourcing module design may introduce security vulnerabilities at the interface between modules and the car (i.e., in the glue code), as well as between distinct modules designed by external suppliers.The latter source of vulnerabilities is caused by feature interaction problems between different modules and this source of vulnerabilities is outside the scope of this article.
Today's vehicles depend on numerous complex software systems, some of which have been developed by suppliers and must be integrated using "glue code" so that they may function together.However, this method of integration often introduces cybersecurity vulnerabilities at the interfaces between electronic systems.In this article we address the "glue code problem" by drawing insights from research on supplier-manufacturer outsourcing relationships in the automotive industry.The glue code problem can be framed as a knowledge coordination problem between manufactures and suppliers.Car manufacturers often employ different levels of intrusiveness in the design of car subsystems by their suppliers: the more control over the supplier the manufacturer exerts in the design of the subsystem, the more intrusive the manufacturer is.We argue that high intrusiveness by car manufacturers in defining module interfaces and subcomponents for suppliers would lead to more secure cars.
To know is to control.
Ishmael Scott Reed Poet, essayist, and novelist

" "
Intrusive Manufacturer-Supplier Approaches Can Reduce Cybersecurity Vulnerabilities

Mohamed Amin and Zaid Tariq
By analyzing various security solutions that have been proposed to improve the overall security of the modern car (Bouard et al., 2013;Herrewege, et al., 2011;Studnia et al., 2013a;Stumpf et al., 2009;Wolf & Gendrullis, 2012;Wolf & Weimerskirch, 2004), we observe that the proposed solutions: i) only focus on providing technical architectures of security solutions, ii) would typically require substantial changes to existing implementation processes in the automobile industry, and iii) do not directly address the glue code problem identified by Checkoway and colleagues (2011).To address these shortcomings, we examined literature on manufacturersupplier relationships.As will be described below, we identified that the manufacturer's level of intrusiveness in supplier design could aid in solving the interface boundary, or glue code, problem.In particular, we argue that, for manufacturers to avoid security vulnerabilities at the boundaries between electronic control units, they should be highly intrusive in the supplier design of the module interfaces and subcomponents that call other electronic control units in the car.
In the following section, we describe the proposed cybersecurity solutions for cars and existing manufacturer-supplier relationships.Next, we examine an existing analytical framework and propose our solution.We close by outlining our contribution and offering conclusions.

Proposed Solutions
Three broad categories of solutions have been proposed by various researchers: i) encryption of communications, ii) anomaly detection, and iii) improved integrity of the embedded software (Studnia et al., 2013a).Table 1 summarizes representative solutions and their salient features.
Manufacturers and suppliers co-develop modules with varying levels of intrusion by the manufacturer in the supplier design (Cabigiosu et al., 2013).

The Manufacturer-Supplier Co-Development Approach
Cabigiosu and colleagues (2013) compared two similar vehicle component co-development projects carried out by the same first-tier supplier with two different automakers.They used an analytical framework to analyze the manufacturer's approach to supplier integration in product development.The results showed that the two manufacturers employed different levels of "intrusiveness" in supplier design.Manufacturer intrusiveness represents the level of detail and the amount of coordination the manufacturer employed in defining the design of the respective artifact.An intrusive approach to the co-development is an approach where the manufacturer exerts high level of control over the supplier's design decisions.The level of intrusiveness influences the knowledge the manufacturer has about the interface and the subcomponents of the module.
Analyzing the two different approaches reported by Cabigiosu and colleagues (2013), and the corresponding degrees of intrusiveness with each approach, leads to insights on how the glue code problem may arise and what car manufacturers can do to prevent it.
According to Cabigiosu and colleagues (2013), manufacturers engage with suppliers at different levels of intrusiveness in: 1. Module-to-car system-level design: includes functional and performance parameters that the module has to adhere to in order for it to comply with overall functional and performance parameters of the car as a whole.
2. Module-to-module interface design: includes protocol-level functionality that the module has to adhere to in order for it to interoperate with various other modules in the car.
3. Individual-subcomponent-to-module system-level design: includes functional and performance parameters that various subcomponents in the module have to adhere to for the module to work as a whole.
4. Individual subcomponents design: functional-and protocol-level parameters that subcomponents have to adhere to.
Table 2 compares the approaches taken by two manufacturers in co-developing an air conditioning system with the same supplier (Cabigiosu et al., 2013).Manufacturer A's approach can be characterized as intrusive whereas manufacturer B's approach can be characterized as non-intrusive.
Table 2. Comparison between intrusive and non-intrusive approaches to manufacturer-supplier co-development (Cabigiosu et al., 2013) Intrusive Manufacturer-Supplier Approaches Can Reduce Cybersecurity Vulnerabilities

Mohamed Amin and Zaid Tariq
The glue code problem can be seen as a knowledge coordination problem.Suppliers design components based on performance and functional specifications provided by the manufacturer.Design decisions can sometimes be left to the discretion of the supplier, who may assume that particular components in the car work in certain ways.This was the case with the Airbiquity software component analyzed by Checkoway and colleagues (2011), where they found that the code calling this component and binding it to other telematics functions made the wrong assumptions about the component supported packet size and resulted in a buffer overflow vulnerability.Packet sizes are usually defined as part of the interfaces; given that the car manufacturer did not know the right packet size used by the software component shows that the manufacturer was non-intrusive in defining this interface.An intrusive strategy would avoid such a problem because the manufacturer would know the right packet size because it was the one defining it.Only the manufacturer is in a position that would allow a holistic view of all the different electronic control units and their inner workings.Thus, the glue code problem can be reduced if the manufacturer employs the right level of intrusiveness with different suppliers.We argue that the right level of intrusiveness by a manufacturer for avoiding the glue code problem is being highly intrusive in defining the module interfaces and the inner subcomponents of the electronic control unit module that call other modules in the car.This degree of intrusiveness in the manufacturer-supplier relationship is similar to a hybrid-control governance model of open source platforms (Noori & Weiss, 2013), where increased control yields higher quality but does require greater effort in the form of overseeing all the parties involved.Where increased quality equates to increased security, this added effort will be worthwhile.

Conclusion
As described earlier, security solutions can by broadly divided into three main categories: i) encryption of communications, ii) anomaly detection, and iii) integrity of the embedded software, where the final category refers to approaches that ensure the car's critical software is not affected by a cyber-attack (Studnia et al., 2013).Our contribution adds to this third category by identifying the manufacturer-supplier relationship that reduces the risk of vulnerabilities at the boundaries between electronic control units and thus protects the integrity of the car's critical software modules.
Our contribution allows car manufacturers to employ the right level of intrusiveness in their supplier design to increase the level of cybersecurity in their cars.It allows individuals responsible for leading engineering efforts at both manufacturer and supplier organizations and individuals controlling manufacturer-supplier inter-firm relations to pick the right working model for building secure cars.We encourage the research community to further explore manufacturer-supplier relationship theory and other managerial theories in their search for a solution to securing the car.
Manufacturers can choose the optimal degree of intrusiveness when co-developing new products with their suppliers.We argue that an intrusive strategy can be employed by manufacturers when developing electronic control units to reduce the risk of cybersecurity vulnerabilities at the boundaries between systems.We invite further research into this domain to tackle the cybersecurity problems of the modern car.Future work could empirically test our claim that increased manufacturer intrusiveness in supplier design leads to more secure cars.

Table 1 .
Representative cybersecurity solutions for the modern car

Mohamed Amin is
an MASc student in the Technology Innovation Management program at Carleton University in Ottawa, Canada.His research interests include cybersecurity, API strategy, and industry architecture.He works as a Solution Architect for Alcatel-Lucent Canada, where he designs and delivers network solutions for various internet service providers around the world.Zaid Tariq is completing his MEng in Technology Innovation Management at Carleton University in Ottawa, Canada.He also holds a BEng degree in Computer Engineering from McGill University in Montreal, Canada.He is a Senior Network Engineer at Cisco Systems and has 9 years experience working in the network design, architecture, and test domains.