The automotive industry runs on software—but increased software increases the attack surface. Vehicle safety starts with automotive software security.
The original version of this article was published in The Security Ledger.
Software is a relatively new human artifact that grows more complex by the year, even as our smartphones and Internet of Things (IoT) devices become easier and easier to use. This is perhaps the highest irony of software: things that seem simple on the surface hide their complexity deep inside their code. And as we will see, complexity is the friend of the attacker.
In the modern world, it is almost impossible to avoid using software, even if you are a serious Luddite. That’s because software has become an invisible, yet essential, part of many everyday things. As just one example, consider the fact that your business’s electric power is dependent on the proper functioning of huge amounts of behind-the-scenes software. Does it really take software to turn on the lights? Yes, it really does. Oh, and it takes lots of software to make your car go too.
Because software has become the lifeblood of modern economies, and because building perfect software turns out to be very difficult indeed, software defects have become inextricably tied to reliability, safety, and security problems. When you embed software invisibly inside everything, that software must somehow be made to behave. For this article, we’ll focus on security and leave reliability and safety aside.
So what happens when we dig deeper into the relationship between software and security in the automotive industry? Let’s start by considering the state of secure software development in other industries, like financial services and healthcare. In 2018, many firms that create software are focused on building systems that are designed and implemented to be secure—in advance. As it turns out, protecting software from hackers is much easier if the software is built to be secure. The notion that you can draw a perimeter around possibly defective and vulnerable software inside your system and protect it with a magic firewall is a fairy tale.
The growing emphasis on software security and the notion of moving security thinking earlier in the software development process is an indispensable insight that all technologists agree on. Identifying and fixing implementation bugs and design flaws early in the software life cycle saves businesses remediation costs and time that could be better spent working on other aspects of their products.
This concept is easily translated by analogy into the automotive space. Car manufacturers aim to make their cars as safe and secure as possible, before they begin rolling off the assembly line into the hungry arms of consumers. It’s important to understand that when engineering a complex artifact like a car—which is quickly evolving to be a smartphone on wheels—manufacturers can’t simply cross their fingers and hope that all their software and all their suppliers’ software is secure. Indeed, as much attention as has been paid to metallurgy, impact protection, seat belts, and materials science to make modern cars safe must now be paid to software to make it secure.
We can stretch this safety analogy further by noting that car safety is not only about crash testing cars into walls. To be sure, crash tests are important. But crashing cars one after another into walls to discover simple problems that are only then re-engineered gets expensive fast. Finding a bug in your software code by running a penetration test, and then fixing that issue well after the software developers have all left the building is similarly cost prohibitive and silly. When it comes to software, there’s a real chance that by fixing some particular bug, you may have inadvertently introduced several more. Who knows? This game of pen test chance isn’t reliable or scalable. For this reason, you’ll be happy to know there’s a more strategic way of going about things.
Engineering is about trade-offs. When car manufacturers are engineering a car, deciding how large the fuel tank should be to average X number of miles per tank is a design decision they must make. Deciding where the fuel tank should be placed in the layout of the car is a similar decision. Some of these decisions may be made by trial and error, but only in a tight feedback loop that converges to a solution well before manufacturing happens.
When things go wrong, they can really go wrong. Take the classic example of the Ford Pinto. Ford neglected to reinforce the Pinto’s fuel tank, which could be easily ruptured in a crash, causing the car to catch fire. Re-engineering plans were presented, but Ford decided that $49 million in damage payouts (allowing the problem to persist without enacting a solution) was preferable to the cost of $113 million to resolve it—a decision that haunts the company decades later. (Heck, it even made it into this article about software.)
As pressure built, based on negative media attention and an investigation into the situation by the National Highway Traffic Safety Administration, in 1978 Ford recalled all Pintos manufactured from 1971 to 1976 for safety upgrades. And here we are, 40 years later, still using this example to prove a point. While security is surely not a thing like a gas tank (it’s really a system property), software is a thing. And software security is something we know how to tackle. In fact, we know that we need to consider security (like gas tanks) during the design phase and then again when the design is implemented in code.
Car manufacturers have a long and distinguished engineering tradition. As more and more software invades this tradition and permeates car design, we must bring the same methodical engineering mindset to bear. Software can be secured. We know how to do it. So we must.
The first step in the direction of software security is making it someone’s job. Build a software security group (SSG), and put an executive with real power in charge of that group. The SSG will be tasked to develop a strong software security initiative in your firm. Note that the SSG is better staffed by software people with security knowledge than by network engineers who know about firewalls!
Establishing an SSG is the baseline requirement for an organization to use the Building Security In Maturity Model (BSIMM) measurement tool and join the BSIMM Community. Now a decade old, the BSIMM has become the de facto standard for software security and building security in. We’re sorry to say that though the BSIMM has well over 100 member firms representing many business verticals, it does not yet have automotive vertical representation. The automotive sector can and should leverage the BSIMM to make rapid progress in software security.
While software in cars is still a concept that’s in its early days, hackers aren’t going to wait for the industry to catch up before poking around. In an ecosystem of increasingly connected systems, from smartphone apps that act as key fobs, to the silicon brains behind autonomous vehicles, there’s way too much that can go wrong. If a system malfunctions owing to a software defect, or if a hacker takes control of a vehicle with malicious intent, things will not be pretty.
For this reason, we must be proactive when it comes to software security and the software that is built into cars. Form an SSG, benchmark your security engineering capability, identify strengths and weaknesses in the software your organization creates (or buys from suppliers), and establish a clear roadmap moving forward to strengthen the security of the software that powers your business and protects your customers.
Spread the word!
At the 22nd International Automobil-Elektronik Kongress in Ludwigsburg in June 2018, Dr. Gary McGraw, VP of security technology at Synopsys, presented “A Brief History of Software, Security, and Software Security: From Mainframes to Connected Cars.” Watch the presentation below.