In modern vehicles, the security of human beings is a top priority. Technologies such as airbags, lane-assist, or automatic brake systems are constantly improved to save more lives on the road. One aspect that is often denied sufficient security measures, is out of all things, a feature that most of these life-saving technologies rely on heavily - the software.
Just like any other software, automotive software can contain vulnerabilities that can be exploited. The difference is that the consequences of a breach in automotive software can literally be deadly.
Due to the high output rate, expected of car manufacturers, application security is often given little attention, in order to focus on issues that are more apparent to the customer. This approach works fairly well at reaching short-term goals. In the long run, this strategy is destined to fail.
The costs of a recall due to buggy software can exceed the costs of investing in the right security measures by hundreds of millions. One of the main reasons, why big automotive firms do not appear to be too concerned about software security, is because there are only few reports of hackers gaining access to vehicles.
This does not come as a surprise, since software that can be hacked remotely has not been around for too long in vehicles. However, vehicle manufacturers definitely should be more concerned. Let’s look into an example…
While most hacks were conducted analogue in older vehicles, the abundance of connectivity platforms in modern vehicles exposes them to remote attacks. As early as 2015, security researchers managed to remotely hack a Jeep Cherokee, while a forewarned reporter was driving it down the highway.
The attackers basically gained control over the whole system, through a vulnerability within UConnect, which is an internet-connected entertainment and navigation unit. While the poor reporter was going down a highway, the researchers toyed with the AC, windscreen wipers, and speaker system. Eventually they shut off the engine completely, leaving the reporter almost at a complete halt with nowhere to go, and an 18-wheeler approaching from behind!
This example highlights just how dangerous vulnerabilities in automotive software can be. The two researchers conducted the hack from over 10 miles away, but they could have just as well done it from the other side of the planet. The breach resulted in 1.4 million vehicles being recalled, causing hundreds of millions of financial damage for Jeep.
The example above highlights how far-reaching the consequences of vulnerabilities in automotive software can be. Making our vehicles more reliant on software has made cars more secure and efficient.
Nonetheless, this digitalization of vehicles has been swift and recent, which created an imbalance between the level of software-dependency and software security in modern cars. If exploited, this imbalance would be a huge risk to public safety.
This should not be one of these instances where something needs to go horribly wrong for us to understand that we need to take action. Especially because it can be so simple! Compared to the incredible feats that have already come out of the automotive industry, developing secure software should be a walk in the park for these firms.
The first step towards secure software is cultural acceptance. Automotive companies need to build a culture in which each and everyone involved in the SDLC (software development lifecycle) understands the importance of security and feels responsible for it. Modern software development approaches such as DevSecOps would be a suitable model to ensure that security requirements are met.
Most automotive companies test their software after product release, which is clearly too late. To ensure that software vulnerabilities do not make it to the late stages of software development, it is crucial to conduct security tests directly within the different delivery teams and throughout the entire SDLC.
Only testing in the late stages is not going to cut it when the life of your customers is at stake. “Shifting left” i.e. implementing early testing, will cost money and time, but compared to the cost of fixing bugs in the late stages of software development or even recalling millions of vehicles, these costs are insignificant. If you want to find out more about the resources that can be saved by early testing, feel free to read up on the rule of ten.
In most companies, static application security testing (SAST) or dynamic application security testing (DAST) are used. However, these approaches, are somewhat inefficient, as SAST is unable to detect runtime issues and DAST requires a lot of manual effort and produces countless false positive test results.
An alternative for these traditional methods, is a testing procedure that is built around feedback-based fuzzing. A feedback-based fuzzer uses feedback about code-coverage from previous inputs to create new inputs that penetrate deeper into the software. This allows it to detect bugs that are hidden deeply within the source code. Modern fuzzing platforms such as CI Fuzz are highly automated and produce basically no false positives - perfect for automotive software development.
Automotive Companies need to make software security a priority now and implement appropriate security measures before it is too late. This will not only make our roads safer but also save them tremendous amounts of money. DevSecOps and feedback-based fuzzing offer a great solution that manufacturers can implement to prevent crashes, and thus they improve the efficiency and accuracy of their testing efforts while minimizing costs.