There is a growing realization of the need to address cybersecurity and information privacy challenges. New functionalities, such as connected cars, have highlighted the stark reality that most automobiles were not built to be a secure environment, even though the modern automobile is from a computational perspective more complex than a fighter jet. With over 100 million lines of code spread among 100 or more processors, the threat surface and number of potential vulnerabilities are huge. In some ways, the challenges are parallel to those we have seen in IT over the past 15 years. But as a mobile computing platform, the car represents many unique security challenges that must be urgently addressed.
Although the automakers understand the concept, the vast majority of consumers do not appreciate the risks inherent in a hacker gaining control of the car from inside or even the outside of the vehicle. Security has to be an inherent design objective and be treated by development teams as seriously as functionality, performance, and reliability.
The industry is faced with a real challenge, with no easy answers. Much of the technology embedded in cars over the past 10 years is now potentially susceptible to malicious exploits that were inconceivable when the cars were designed. Connected vehicle technology now exposes these insecure systems to real threats. The electronic control units (ECUs), transmission control units (TCUs), and other critical on-board functionality are more and more vulnerable to rogue data and instructions that could affect safety, whether these attacks are injected over the Internet, via Bluetooth, through near field communications (NFC), or directly through the onboard diagnostics (OBD) port. Unfortunately, the counter-measures are difficult to implement because of the obvious differences between a car and a traditional networked computer. For example, the life expectancy of a car is about 12 years versus a personal computing device, which is replaced more frequently. Because of this and other reasons, it is either impractical or impossible to retrofit a secure computing environment into most vehicles; plus, how can one safely update automotive software without requiring a trip to the dealer? The over-the-air (OTA) software update industry is new and itself fraught with security challenges. Nevertheless, we expect to witness an industry awareness and maturity process that parallels that of the PC industry, but hopefully with a faster maturity cycle.
This cycle has three phases: The first is typically a panic and a scramble for quick fixes; the second phase is what we call the “pit of despair,” where the scope of the challenge becomes obvious and successful exploits are publically acknowledged, and the final phase is the realization that there are no quick fixes and that an organization-wide approach is needed to address security as a core business process. GM’s appointment of a cybersecurity czar is an example of phase-three thinking. Only once an original equipment manufacturer (OEM) reaches this level of organizational awareness can they start to develop the structure, tools, and processes to build a more secure vehicle or mitigate the impact of previous engineering decisions. It’s at this point we see processes being created, tools getting developed, and experts such as Security Innovation being invited to help with threat modeling, penetration testing, risk ranking, gap analyses, and other security services.
There are many ‘attack vectors’ the OEMs must think about: internal, external, and intra-vehicle. Internally, these include the DVD player, USB, aux input, and, most dangerously, the OBD port, which is the area we believe OEMs need to focus on most. Direct injection into CAN bus, high-speed media bus, or Ethernet are also risks.
Externally, vehicles are now accessible through Bluetooth, the Internet, and NFC devices such as the key fob or the tire pressure monitoring system. The CAN bus is also accessible from outside the vehicle, with an already documented ability to inject malware by removing a tail light. However, inter-car communication such as vehicle to vehicle (V2V) is by far the most secure system by design. The digital short-range communications (DSRC) environment has been developed with security as a primary design criterion, but alternative implementation paradigms such as LTE may not be as robust.
Automo suggests that both security and information privacy must be treated as equally important. However, the first step should be a comprehensive risk assessment that addresses the five traditional indicators of risk, namely motivation, feasibility, impact, threat status, and scale.
DSRC the high-speed and low latency of 5.9 GHz short-range radio link is independent of other in-vehicle protocols and non-interruptible. However, any safety application that uses 4G or LTE is susceptible to interruptions, and, therefore, compromised safety. Think of a family traveling in an area where there is less than perfect mobile coverage, with two or three children streaming video or playing games that happen to use high bandwidth. In this scenario, the safety functionality may be limited.
Security Innovation: Automo look at five different aspects of risk analysis, and those are as follows:
Motivation: Modern cars are essentially wallets on wheels, so for people motivated by the theft of financial data, the car is a potentially valuable target. And although it may seem far-fetched, extortionists, enemies of the state, or simply aggrieved people could turn a car or fleet of cars into a weapon.
Feasibility/Cost: How complex is the threat? What is the risk?
Impact of the Attack: If the vehicle is successfully hacked, what will the impact be? Could someone take control of the vehicle? Could someone acquire personal and private data that is stored in the vehicle?
Status of the Threat: Sometimes threats are only theoretical or experimental, and, therefore, impractical. Others are so hard to pull off that only the most persistent attackers will succeed, and then usually only on an individual vehicle.
Scale: Can the attempt or exploit affect one or more vehicles? What is the potential impact of a hacker taking over a fleet of vehicles and then using blackmail or extortion to achieve their financial or political objectives?
Building better security into new vehicles is happening already. A tougher challenge is how to address vulnerabilities in the connected vehicles already on the road. How can these threats be mitigated; how is software updated; how should the industry address zero-day vulnerabilities?
These are all important questions, and, once again, there are no simple answers. We know there is no single solution, no magic bullet. An in-depth defense approach is needed that will require the application of traditional IT mitigation techniques such as network segmentation, cryptography, virtualization, black and whitelisting, intrusion detection, trusted platform and trusted execution, and many more buzzwords. In short, the solution must be holistic.
Unfortunately, a reality of the security world is that the manufacturers need to be right 100% of the time, while the bad guys only need to be right once.
To put things in perspective: NASA achieves zero errors per line of code, a goal which they’ve achieved and which frankly will not happen in the automotive space. However, this must be the objective. So a cornerstone, historically and today, is to do whatever possible to improve the security of software.
At present, companies are working towards minimising the impact of a threat by approximately 80% of all exploited vulnerabilities which can be further tied back to the application layer, so if a hacker gets through the firewalls and if the applications are not written in a secure way, it becomes relatively easy to exploit the system.
The world is not aware of any malicious OTA hacks yet. But they are inevitable. Unfortunately, this is the world we live in, and all we can do is help the industry to be as prepared as possible for the security threats posed by greed, fraud, pride, or malice.