It’s going to be a while before autonomous vehicles (AV) are mainstream. Don’t expect, anytime soon, to summon a driverless car with an app, hop into it a couple of minutes later and settle in with a book, a movie or to take a nap while it takes you anywhere you want to go—the next town, a nearby city or a few states away.
Charlie Miller and Chris Valasek, they of the famous 2015 remote hack of a Jeep Cherokee, are working full time on getting AVs ready for prime time, and even they wrote in a whitepaper last summer that it will likely take at least a decade for AVs to dominate America’s roads.
That’s both because of how complicated it is to make computers as capable as a sober human to drive a car, and because of the need to make all that computing power resistant to cyberattacks.
The two, who have been with General Motors’ AV division Cruise for 18 months, explained in a blog post last week how they are setting priorities for security in AVs.
All of which is necessary—if AVs are ever to become mainstream, consumers will have to trust them, and who better to figure out how to make them secure than a couple of superstar hackers?
But that doesn’t mean the need for cybersecurity of vehicles is all in the future. Today’s “pre-autonomous” fleet is very much connected. As you can see every day in TV ads, the list of computer-controlled and connected features includes adaptive cruise control, GPS, back-up cameras, side-mirror cameras and “lane assist,” which drove me crazy when I was using a rental last fall.
eBook
Securing the Modern Vehicle
Secure autonomous vehicles—starting today
The point is, cars on the road today are just as much in need of security—actually more immediately in need, since they aren’t being driven in controlled environments.
Indeed, the amount of computer control of vehicles today is staggering. As multiple experts have noted, a Dreamliner jet has about 6.5 million lines of code, while a Ford pickup has almost 20 times that—130 million. That truck also has about 100 different chips, more than two miles of cable and 10 operating systems.
And while those connected capabilities provide almost magical convenience and improve physical safety when they work as intended, it is also well known that too much of the code is vulnerable to tampering—as in remote hacking. The kind of thing Miller and Valasek did four years ago, when there were perhaps only a measly 80 million or so lines of code in vehicles.
As the capabilities and connections have grown, so has the attack surface. That was confirmed by those in the industry, who ought to know, earlier year in responses to a survey sponsored by Synopsys and conducted by the Ponemon Institute. Of nearly 600 respondents, 84% said they had “concerns that cybersecurity practices are not keeping pace with the ever-evolving security landscape.”
In other words, while the future of automotive technology is important, the security of what is in use today is arguably a much more important priority.
Priorities for secure autonomous vehicles
So, what should the security priorities be for today’s fleet?
Andrea Palanca, a hacking researcher and member of a team that two years ago demonstrated the viability of an attack on vehicle control systems through a vulnerability in the Controller Area Network (CAN) Bus standard, said the biggest barrier is that it is difficult to patch known vulnerabilities in the code for computers and sensors that control everything from infotainment to safety systems like steering, acceleration and brakes.
Not only are those devices produced by a global supply chain diverse enough to make anyone’s head spin, he noted that they are also a product that is in use for 7–10 years—“undoubtedly longer than other electronic consumer devices.”
And given that a majority of the existing fleet is probably more than four years old, many of them were not designed for remote, or over-the-air (OTA), patching.
Implement security by design
“The priority for car makers for the existing fleet should be to design a sustainable way to maintain a list of embedded computers inside vehicles, and then promptly reach customers should security flaws arise so they can apply patches to components,” he said.
Dennis Kengo Oka, applications engineer, senior staff at Synopsys, doubts that the OTA problem will be resolved within the current fleet. “It has to be security by design,” he said, “and it will take a few years until we see the next generation of vehicles that are built with that.”
Perform a risk assessment of your portfolio
Art Dahnert, managing consultant at Synopsys, agrees that the “many different models and configurations” of an automotive fleet make an effective security initiative complicated.
So he recommends the same thing he does to non-automotive clients. “Perform an assessment of your ‘portfolio,’ including identifying and ranking the potential risk areas,” he said.
And given that U.S. traffic accidents claim about 40,000 lives per year, he said the top priority for current vehicles “would definitely start with safety.” Whether access to a vehicle is remote or physical, carmakers should “make sure the vehicle’s safety components can’t be compromised. This will involve a layered approach with a lot of separation and untrusted connectivity assumptions.”
Limit inbound connections
He said another priority should be to reduce the risk of remote connection attacks that could compromise the entire fleet by “thinking long and hard about inbound and outbound connections over various networks, focusing on LTE [cellular] as well as Wi-Fi and BT [Bluetooth].”
Indeed, one of the elements that Miller and Valasek say is essential for the security of AVs is to allow only outgoing communications from vehicles. “No inbound connections over the Internet should be possible. Only outbound connections will be allowed,” they wrote.
Special considerations for AV security
But again, that kind of security does not exist today. Oka, who with Synopsys colleague Rikke Kuipers will be presenting a talk on improving fuzz testing of infotainment systems and telematics units using agent instrumentation at the escar (Embedded Security in Cars) USA conference in June, said securing vehicles involves complexities beyond those of a standard small enterprise network.
Among them, the ECUs (electronic control units) in vehicles “are typically small microcontrollers with limited memory and CPU processing power, and the in-vehicle network bus has limited bandwidth,” he said. That generally makes it impossible “to employ heavy cryptographic calculations or include large signatures on messages.”
Speed is a factor as well—not the speed of the car but of computer calculations. “A computer or a mobile phone can take 30 seconds to a minute to boot up, and people are OK with that, but there is no driver who would accept a vehicle that takes 30 seconds to start the engine because all the ECUs have to run through secure boot and verify digital signatures, etc.,” he said.
“Also, if a driver, or self-driving car, detects an obstacle and applies the brakes, the brake ECU cannot take even one second to verify that the brake message is authentic.”
How to build security into autonomous vehicles
Bottom line: While nothing made by humans is entirely bulletproof, vehicle security can get a lot closer by making software secure before it is embedded into a vehicle. And that means doing what has become a mantra at security conferences—“build security in” during the entire SDLC (software development life cycle).
Oka and numerous others refer to it as “shifting left,” meaning testing for vulnerabilities from the beginning of the SDLC, and not just at the penetration testing phase at the end.
It also requires multiple types of testing, he said, listing “code reviews, static code analysis, using checkers for secure coding guidelines, software composition analysis and fuzz testing early, and preferably in a CI [continuous integration] environment, to allow for regression testing also.”
And, Dahnert notes, that testing needs to go beyond what is inside the vehicle—obviously a connected car is communicating beyond its “skin.”
“All software that is not on the vehicle but communicates with vehicle should be vetted,” he said. “The back end and mobile support infrastructure is crucial to today’s connected vehicle and the autonomous vehicle of tomorrow.”
Plans underway to secure autonomous vehicles
Amid all this is some good news: Not only is there increased awareness of the need for security in connected cars, but there are also initiatives to do something about it.
“There is a new cybersecurity engineering standard called ISO 21434 planned to be released in August 2020,” Oka said, “and there is a regulation driven by Europe for autonomous and connected vehicles called UNECE WP.29, which also probably will be released in 2020.
“OEMs and suppliers will have to change their processes to incorporate cybersecurity and will definitely lead to improvements in software security.”
eBook
Securing the Modern Vehicle
Continue Reading
SANS report: Securing the shifting landscape of application development
