(c)iStock.com/Jirsak

Compromising the ‘Internet of Things’ seems to be one of the most ‘fashionable’ areas among today’s hackers, including connected cars. Just consider the extensive coverage given to the remote takeover of a Jeep Cherokee by security researchers Charlie Miller and Chris Valasek, which took place via a security vulnerability in the car’s UConnect infotainment software. 

While much of the concern may be around individuals hacking into vehicles that are already on the road, it is essential to look back at the software development process itself, because this is where vulnerabilities can creep in.  Given that hackers are an incredibly inventive bunch, and if there is a will there is a way, then clearly automotive manufacturers need to cover every aspect of security.

After all, when a mobile app crashes due to a bug, it’s annoying and could potentially lose the app some users, but in the connected car world, even a minor problem that crept in during the development process could have catastrophic consequences. For example, in 2014 Honda publicly admitted that a software defect in an electronic control unit (ECU) caused unintended acceleration and recalled 175K hybrid cars.

Even if physical harm may not be the result, the cost of managing recalls and the associated reputation risk should not be under estimated.

Today, mainstream cars may already contain tens of millions of lines of software code, executing on over a hundred electronic control units (ECUs). With the advent of connected cars, the volume of code involved can quickly reach a whole new level. For instance, they may need code updates more frequently, including over-the-air, which could open up even more security breach concerns.

Separating systems out so that safety-critical functions – such as braking, steering and acceleration - are isolated is part of the answer. Even if safety systems were isolated, there is still a multitude of external communications that connected cars have, such as Wi-Fi updates, GPS sensors, remote diagnostics and so on. Any of which could present a potential vulnerability.

A common, visible foundation

So what can be done? The answer lies in creating greater visibility across the whole design process, both enabling a more collaborative approach among different contributors and making the entire development history open to investigation if required in the future.

Let’s start by looking at the code languages being used, notably C and C++, which car and component manufacturers have been wary of moving away from, due to legacy code investments, smaller memory footprint, real-time execution constraints and the need to write low-level device drivers (although alternatives to the latter, such as Rust and Ivory, are making a difference).

The problem is that C and C++ can pave the way for security attacks, for instance via format string attacks, buffer overflows, dangling pointers and privilege escalation bugs. Moving away from these development platforms is not something that can happen overnight in many instances, however the automotive industry is looking at ways to address and deal with the risks around code development, some of which have been around for some time now including the Motor Industry Software Reliability Association (MISRA) coding standards which should prevent the use of risk code constructs.

Static analysis tools can scan source code or version control repositories to catch non-compliant code, identify software flaws or potential vulnerabilities. Other tools can detect policy violations, flow analysis, code reviews and run-time errors to identify memory leaks and buffer overflows during the build and test process. International standards such as ISO26262 are being defined and widely adopted to prove functional safety.

But the issue isn’t solely in software. The best practice for design and development for security and safety would consider both hardware and software holistically. This has been difficult in the past because of the very different toolsets being used, but today there are modern version management systems that can handle both hardware designs (and related assets such as simulator definitions, test scripts) and software source code. Where a single repository is being used, it is possible to avoid gaps and misunderstandings across all teams and processes.

Third party integration challenges

One of the biggest challenges in automotive software design is the fact that there are typically so many contributors in the process, with components being supplied by third parties. Most ECUs, for instance, come from third-party suppliers as a “black box” built to the manufacturers’ requirements and give little visibility into how the hardware and software was developed.

However, given that those manufacturers ultimately take responsibility if something goes wrong, then they need to have detailed knowledge of every component and version of the software running their connected cars. Eventually, we may also have an open architecture containing standards that provide a common framework for all component builders, thanks to the Open Automotive Alliance.

Managing source code complexities

In the meantime, a comprehensive version control platform will contribute greatly towards a more transparent and collaborative environment. Solutions in this category that are able to not only connect internal teams but also third parties – even when multiple platforms or development tools are involved – will give everyone the ‘audit trail’ of what happened where, how and by whom, while helping to ensure compliance with standards.

It is vital to use a source code or version control system that is inherently secure, enables different levels of security and is able to scale to manage extremely large volumes of digital assets across hundreds or even thousands of developers and contributors.

Given that cars are likely to become increasingly dependent upon software, it makes sense to secure as much as possible. Reducing the vulnerabilities that could be created in the development process is a good place to start and while 100 per cent foolproof security is not something anyone can promise, there is much more that can be done towards achieving that goal.