According to Gartner, by 2020 an estimated 250 million connected cars will be on the roads worldwide. It’s easy to see why, as the potential benefits for automotive manufacturers in connecting their cars to the Internet and each other are significant.
With OEMs pushing to create increasingly connected vehicles and components, the modern car is in the midst of unprecedented change. New connected elements sit uncomfortably alongside aspects of car design that have not changed at the same pace. Modern electronic control units, advanced sensors and software are integrated with legacy parts within a car such as older embedded systems. In its basic construction, the car was never designed with so much connection in mind. This blend of new and legacy components means that as the car becomes more connected, its vulnerability to digital attacks grows – and so does the potential damage one can cause.
Cyber security is therefore becoming a key concern for manufacturers. However, many are considering security, whether it be for a new part or the entire car, later in the development process. This is the wrong approach.
‘Shift left’ – a new mindset for the automotive industry
The automotive industry could benefit from adopting a mindset found in other areas of IT, where teams take the quality assurance of a product or service into account at the earliest stages. It’s worth noting that these teams work in a quick production environment, which is far from the world of embedded systems in the automotive sector, but nonetheless the core principle can deliver important lessons for the industry. In the world of software, this approach is called ‘shift left testing’, a term that stems from moving testing ‘left’ on the project timeline to come earlier in the lifecycle.
OEMs face a complex supply chain, with electronic components developed by a multitude of suppliers. Car brands have little insight into the development processes at their suppliers, particularly their software architecture or code
The reason for this is obvious. A defect or risk found and treated in the initial stages of development is the cheapest one. Detecting errors later in the process will have greater impact – be it in the manufacturing cycle or after the vehicle is launched, when fixes are inherently more complicated, or even after a hack has occurred and customer trust has been lost.
An additional challenge OEMs face is a complex supply chain, with electronic components developed by a multitude of suppliers. As a result, car brands have little insight into the actual development processes at their suppliers, particularly their software architecture or code. However, a ‘shift left’ approach can be effectively adopted here also. Test strategies in such cases may include checking test logs or to have a third party review source code and processes. If a code review or white-box testing is not possible, it may still be possible to perform grey-box and black-box pentesting.
A requirement for continuous security
This mindset of testing early doesn’t just apply when designing a new model, but also when updating and upgrading parts for existing models. Every new function or any change that is made can impact security.
For example, when a manufacturer wants to extend a remote update capability to an additional channel such as Bluetooth, this increases the attack surface of the vehicle. In order to mitigate against this, an OEM should perform a risk assessment to balance benefits against potential damage in the earliest stages of design – something it should be undertaking for each and every new or changed functionality. In many cases, the potential risks highlighted by this assessment can be addressed through technical measures in one of the electronic control units, which can be expressed as various kinds of security requirements.
Such security requirements, functional behaviours that enforce security, are critical to prevent damaging attacks. Risk assessments are not the only source from which OEMs can develop security requirements, which can be based on anything from security principles to external regulations.
In the world of software, the term ‘shift left testing’ stems from moving testing ‘left’ on the project timeline to come earlier in the lifecycle
Even with a shift-left mentality and strong security requirements, given the complexity of in-vehicle software it is unrealistic to expect completely error-free software upon the launch of a new car, component or update. Once a vehicle leaves the factory floor and the direct control of the manufacturer, it’s important that the car can be monitored for security anomalies and that it is possible to remotely update its security status via, for example, over-the-air (OTA) software updates.
Putting in place security operations, which includes security monitoring, allows for quicker and well-managed reaction to hacks and a reduction in the window of exposure – basically the time it takes to fix a vulnerability in any vehicle.
From steel to software
While a traditional outlook that considers cyber security late in the process and a supply chain that is difficult to control are issues that are not exclusive to the automotive industry, they are both so entrenched that they present what is perhaps a unique challenge.
For an OEM to change its entire approach to cyber security can be extremely difficult. This is, after all, an industry that for many years has specialised in steel rather than software. However, in this era of the connected car, it’s critical for every OEM to blend existing expertise in manufacturing and hardware with a more ‘digital’ approach. This means car brands have to adopt a mentality where at the earliest stages of R&D they are as comfortable considering cyber security as they are steering and braking systems.
