Automotive security can trace its roots back to the earliest beginnings of the automobile itself. Once cars became targets of theft, manufacturers responded to the demand for more security. As techniques were developed to circumvent those early locks, the industry stepped up with newer technology such as ignition locks and designs to fight the use of “slim jims” to open doors. In the second half of the last century, the public demanded alarm systems both from the aftermarket and as factory-installed options. Safety followed a similar path, from bumpers on early models to modern crash avoidance and protections such as airbags that are now mandatory.

As we’ve entered the “always on, always connected” digital age, however, digital security has failed to keep up. The auto industry is in a constant struggle to respond to problems encountered in the real world. While this isn’t new (manufacturers have been dealing with recalls for decades), what is new is that, in many instances, these problems are now tied to software. Toyota’s 2010 hybrid anti-lock brake software recall, Fiat-Chrysler’s 2015 recall of over a million vehicles to fix a software security flaw discovered by an independent researcher, and, most recently, the case of the first fatality in an autonomously driven vehicle, a Tesla, are some examples. More broadly, a report from financial advisory firm Stout Risius Ross showed that the percentage of vehicle recalls attributed to software problems tripled between 2011 and 2015.

This isn’t surprising--cars today are run almost entirely on software. The age-old problem of software development failing to “build security in” is leading to insecurity in automobiles today. The problem starts at a fundamental level: Technology is usually designed around functional requirements. Security faults arise from nonfunctional requirements--preventing bad things from happening. Without secure design expertise injected into the development of automotive software, the game of cat and mouse between attackers and defenders will initially be won by the attackers.

Beyond secure design, there is also the problem of implementation. Even a strong design can fall victim to mistakes made during coding. And, like most software developers, automotive and embedded-software engineers aren’t always concerned about security. They aren’t trained to think about how their code can be used in ways that challenge their assumptions about the way it’s intended to work. This is normal; software developers are trained and paid to build software, to create new features and functionality. They normally aren’t trained how to break it. This can result in software that fails in unexpected ways on the road.

The auto industry needs to start thinking like today’s attackers. As early as possible, engineering teams must bring in security experts who can help point out problems in design and requirements. Teams must perform detailed security analysis on new and existing designs, using recognized software security techniques such as threat modeling. By including security experts in the software development life cycle, the teams will get a different perspective on how their software can be abused once it lands on showroom floors. This effort can then be validated through the use of penetration testing prior to final production, to catch any implementation-level mistakes.

Many new initiatives in the industry will revolutionize the way the public uses vehicles. These include automated self-parking, self-driving cars, and computer-based ride-sharing technology, to name a few examples. These new technologies will require software to communicate with vehicles that are on the road as well as detect and avoid pedestrians, road debris, highway infrastructure, etc. All of this will require software to interpret and respond to millions of pieces of data per mile traveled. If the design of this software can’t keep out malicious data, or if choices made by the designers don’t stand up to real-world testing, then lives can be lost.

In the past, automotive companies would invent technology to offer as optional equipment. If the technology demonstrated increased safety, it might end up as a government-mandated standard feature, such as airbags and anti-lock brakes. However, doing the same for a purely software-based features might be very difficult. That’s because software weaknesses (design flaws, implementation bugs) can go undiscovered until the proper conditions exist to bring them to light, which may not happen as part of standardized regulation or certification.

In other words, the automotive industry needs to embrace a new culture of security, much like other industries have done to reduce risk to their customers. (Microsoft, with its Security Development Lifecycle effort, is one example.) Now more than ever, the security of a vehicle is directly tied to its safety. Understanding how other industries have addressed the software security challenge is a first step, which will allow the auto industry to head off some of the problems that are beginning to show up more frequently (such as Volkswagen’s poorly designed remote key fobs). Some of the manufacturers are already moving in this direction; however, it’s a slow progression and it won’t be enough to keep pace with current technology. This cultural shift needs to happen as fast the technological shift. Is the auto industry up to the challenge?

Related Content: