How likely are weaponized cars?
It is easy to become absorbed by the exaggerated Hollywood depictions of car hacking scenarios – to imagine a not-so-distant future when cars or their supporting infrastructures are hacked by criminals or terrorists and turned into lethal weapons. There are reasons why such a scenario has not happened yet. But could it? And if so, how can we prevent it?
Some might argue that the likelihood of cars being weaponized is extremely low, but from a purely technical standpoint, there is nothing stopping attackers who invest the time and effort from achieving such a feat. After all, the most fundamental property of a computer system is the software that governs the operation of the device. Software is inherently susceptible to a wide variety of threats and vulnerabilities. Under the appropriate conditions, any system may be compromised and its behavior altered, leading to undesired consequences.
How does that affect vehicles?
Technological advancements of the last 20 years or so have led to a dramatic change in the core definition of what a vehicle is. Traditionally, a vehicle was understood to be an isolated mechanical machine, powered by fossil fuel, and driven by a human. This definition is evolving as automotive technology evolves.
The modern vehicle can be described as electric, connected, software embedded, driverless, and even artificially intelligent. Left unmanaged and without security considerations, these properties render risks that manifest as software bugs and design flaws that may allow unauthorized remote access. As vehicles become ever more connected and as software spreads into more and more safety-critical systems, these bugs and flaws present an opening for a catastrophic failure, which may result in injury or even loss of life.
Up to this point in the discussion, we’ve only explored the threats to a single vehicle. When we look at this threat at scale, we’re talking about how smart, connected, autonomous cars could be the 21st century’s weapon of mass destruction. Just imagine fleets of remotely controlled—or even worse, autonomous—vehicles slamming into everything in their path.
The automotive industry is not oblivious to these risks—far from it. And regulatory bodies have drafted legislation, standards, and compliance requirements designed to prevent such catastrophic failures. But as history has shown us, time and time again, even when rigid and compulsory compliance requirements such as HIPAA (medical), PCI (finance), and ISO are enforced, they aren’t enough to prevent some of the most notorious breaches and data leaks.
We need to acknowledge that there is an underlying force at work here. As humans are inherently exposed to health hazards, the automotive industry is susceptible to software quality issues that lead to cybersecurity threats.
Let’s now take this examination one step further and look into the DNA of automotive companies to articulate the challenge at its core: the reality of vehicle production.
Order of magnitude disruption
Historically, automakers were experts in designing and managing the production of vehicles in high volumes under strict quality and safety requirements. In this case, “quality” was mostly a question of luxury, performance, and ride comfort, and “safety” was defined and measured as a derivative of collision tests, fault tolerance, and other attributes reflecting the vehicle’s ability to protect the driver, passengers, and surrounding pedestrians from injury in an accident. This paradigm was embedded deeply into the design, production, and manufacturing processes of vehicles.
Along came cyber
But then everything changed. This change didn’t happen overnight. It wasn’t announced ahead of time so that the industry could plan accordingly. Instead, over two decades, vehicles gradually became specific attack targets.
“Safety” has become a derivative of secure software development life cycle (SSDLC) practices, and “quality” has become the ability to enforce software quality downstream in the software supply chain.
For a car manufacturer to produce safe and secure vehicles, it’s not enough to have engineers use the best materials, optimize airbag deployment, and incorporate advanced driver assistance systems (ADAS). The software code governing these systems must be written with security in mind. The networks that connect these components to one another and to the outside world must be separated, segregated, demilitarized, encrypted, and firewalled.
Systems must be continuously monitored for anomalies. Applications and communication must be whitelisted. External entities must be authenticated and verified. One might even argue that several critical aspects are still missing from this cybersecurity controls grocery list (e.g., incident response and disaster recovery).
A foreign mindset
Many automotive companies view these notions as somewhat foreign. As Ponemon research indicates, most organizations do not have the right talent pool, experience, and infrastructure to address these challenges. The gap isn’t limited to technical knowledge in the workforce and budget allocation. Rather, it also exists in the organization’s ability to adopt the mindset needed to function in a hostile environment where malicious actors operate, and software bugs make news headlines. In the past there was never a need to design a system that could cope with a malicious agent.
To make matters worse, what is perhaps the most fundamental feature in the software world—the ability to easily patch and update systems—is a rare commodity in the automotive world. In the Ponemon automotive study, only 37% of respondents reported that they support “over-the-air” updates, and 25% reported that they don’t deliver security updates at all. This means that to update systems and fix security issues, the majority of the auto industry relies on owners to deliver their vehicles to the dealership for maintenance. When vulnerabilities are serious, this procedure is unavoidable and leads to what is probably the most dramatic and reputationally damaging event in a vehicle platform’s life cycle: a recall.
Organizations such as Microsoft and Adobe can release a security fix to their customers every week, sometimes even without having to disclose the nature of the security flaw in the system. A car manufacturer, on the other hand, is required by law to publicly announce the risk identified and absorb the financial cost of individual car owners bringing their vehicles to a service center for remediation. This cost doesn’t take into account the lawsuits and class actions that often follow such disclosures.
Can we prevent it?
Unfortunately, no. But this answer may be less consequential than it seems, because we are asking the wrong question. The consensus among security professionals is that there is no reasonable way to create a system that is 100% protected, 100% of the time. But perhaps we shouldn’t define our goal that way. Instead, we should focus on fixing the underlying issues that are perpetuating the problem. Here’s how to get started:
Embed security. Having a skillful development team that stays well informed of the risks that unsecure code creates and infusing secure coding methodologies into every step of vehicle design and production are a guaranteed path to a higher-quality product with fewer weaknesses and vulnerabilities.
Rigid supply chain management. Apply the “zero-trust” security principle to the supply chain. Enforce strict controls on the use of any third-party code (with an emphasis on open source code). Manage an inventory of all software packages in use. Subscribe to a threat intelligence service that provides proactive alerts for newly discovered weaknesses and vulnerabilities.
Create mature security practices. Understand that software security is a marathon, not a sprint. Every organization in every industry faces similar challenges, and we can learn a lot from what others have already achieved. Cybersecurity is a field where having good benchmarks, collaborating with others, and making incremental improvements pays off. Gaining visibility into the process of improvement and having a framework to manage a path to maturity are instrumental in making sure the resources and efforts devoted are yielding optimal results.
As is often the case with such complex problem domains, there is not a simple “step-by-step” solution to follow for complete remediation. The strategy to build robust and secure systems has various aspects beyond technical implementation. The three principles listed above are a good, solid start down the path to more mature and secure systems. But they are just that: a start.
To achieve the ultimate goal of a smart transportation solution that is not an easy target for malicious agents, we need to work together as an industry. We must promote knowledge sharing, collaborate in creating the frameworks for guidelines and standards, and constantly improve the tools and talent tasked with this responsibility.