The DNA of a Systematic Automotive Failure

By Matan Scharf, Senior Security Solutions Manager at Synopsys Software Integrity Group

With so many exaggerated Hollywood depictions of car hacking scenarios, it’s easy to become absorbed — to imagine a future in which cars are hacked by criminals or terrorists and used as weapons. While there are reasons why such scenarios haven’t yet taken place, could they? And if so, how can we prevent them?

While some may argue that the likelihood of cars being used as weapons is quite low, from a technical standpoint, there isn’t really anything stopping attackers who invest the time and effort in succeeding.

Modern cars are controlled by computer systems, and 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 right conditions, any system  may be compromised, and its behaviour altered, leading to less than desirable results.

The advancements in technology over the past 20 years have led to a substantial change in the definition of what a vehicle actually is. Traditionally, vehicles have been understood to be isolated mechanical machines that are powered by fossil fuel and controlled by a human. However, this definition is evolving as the technology powering vehicles evolves.

Modern vehicles can be described as electric, connected, software embedded, driverless, and even artificially intelligent in some cases. If they’re left unmanaged and without security mechanisms in place, such properties render risks that manifest as software bugs and design flaws that could allow unauthorised remote access. As vehicles become more connected and as software continues to spread to more safety-critical systems, these bugs and flaws present an opportunity for catastrophic failure which could lead to devastating effects for humans.

If we then examine this threat at scale, smart, connected, autonomous cars could be a widespread weapon of mass destruction. Thankfully, the automotive industry isn’t oblivious to these risks—far from it. Regulatory bodies have drafted legislation, standards, and compliance requirements designed to prevent such failures. And yet, compulsory compliance requirements haven’t always been enough to prevent some of the most notorious breaches and data leaks we’ve seen emerge in recent years.

The Ponemon Institute recently released a report commissioned by Synopsys and SAE International offering a comprehensive look into the core reasons for these issues and factors contributing to them. It highlights a lack of skills and resources, an inability to communicate risks effectively to management, time-to-market constraints that take priority over software quality, and more.

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.

Historically, automakers have been 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 comfort. “Safety,” on the other hand, 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 deeply embedded into the design, production, and manufacturing processes of vehicles.

Everything changed with the emergence of cyber considerations. While this change didn’t happen overnight, it wasn’t announced ahead of time so that the industry could plan accordingly. Rather, over the past 20 years, vehicles have gradually become attack targets. The definition of safety has become a derivative of secure software development practices, while quality has become the ability to enforce quality downstream in the software supply chain.

In order for car manufacturers to produce safe and secure vehicles, the software code governing the systems operating the vehicle and its various elements must be written with security considerations. For instance:

  • The networks connecting components to one another and to the outside world must be separated, segregated, demilitarised, encrypted, and fire-walled.
  • Systems must be continuously monitored for anomalies.
  • Applications and communication must be whitelisted.
  • External entities must be authenticated and verified.
  • The list goes on.

Many automotive companies view these notions as somewhat foreign. As Ponemon research indicates, most organisations 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. 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.

We must also consider that 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. Only 37% of the Ponemon automotive study 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 a recall.

Organisations like Microsoft and Adobe can release security fixes to customers every week, sometimes even without having to disclose the nature of the security flaw in the system. A car manufacturer, however, 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 also doesn’t consider the legal fallout that often follows.

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 perpetuating the problem.

Here’s how to get started:

Embed security

Acquire a skilled development team that stays informed of the risks that unsecured code creates and infusing secure coding methodologies into every step of vehicle design and production. This is a guaranteed path to a higher-quality product with fewer weaknesses and vulnerabilities.

Implement 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). 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

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.

There isn’t 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 strong start on your journey to more mature and secure systems.

To achieve the ultimate goal of a smart transportation solution that isn’t an easy target for malicious agents, the industry must come together. 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.