IEEE Talks Transportation Electrification: Stacy Prowell

Dr. Stacy Prowell is a distinguished lecturer for the IEEE Transportation Electrification Community. Dr. Prowell serves as the Chief Cyber Security Research Scientist in the Computational Sciences and Engineering Division at Oak Ridge National Laboratory. He is the Program Manager for the lab’s Cybersecurity for Energy Delivery Systems program and is the Director of the lab’s Vehicle Security Center. His research focuses on physics-based methods for intrusion detection and semantics-based methods in malware detection and analysis. In this Q&A, Stacy discusses some of the major reasons why vehicles are increasingly vulnerable and what automakers and their owners can learn from the IT world’s security challenges.   

Question: What are some factors that make it challenging to secure today’s vehicles?  

 

Stacy Prowell: For starters, they have an average of 100 million lines of code and 60 control units. Those amounts will continue to increase because automotive manufacturers and aftermarket providers are continually adding safety, entertainment, navigation, telematics and autonomous driving features.

 

Complexity breeds vulnerability. That’s been the case in IT for decades, and now it’s becoming the case in the automotive space. More lines of code, more control units, more interaction between those applications, more vendors—it all adds up to more opportunities for hackers to find weaknesses to exploit.

 

Question: What are some examples of potential weaknesses?

 

Prowell: Four years ago, a couple of white hats conducted proof-of-concept attacks on a Ford Escape and a Toyota Prius. They remotely disabled the brakes and commandeered the steering wheel. Those are examples of attacks conducted over wireless, usually cellular. But many cars now use cellular to create Wi-Fi hotspots for their occupants, so those rolling wireless LANs also could become back doors.

 

Other attacks are wired, via the on-board diagnostics (OBD) port that’s in every U.S vehicle manufactured since 1996 and every European vehicle since about 2001. As the name implies, the OBD port is used by repair shops to communicate with the vehicle’s systems to help diagnose problems. If a hacker can get malware onto a shop’s diagnostic infrastructure, then it could spread to every vehicle that serviced there. An infected vehicle also could be the way that the malware gets into the shop.

 

Yet another potential entry point is infotainment systems. These are now practically standard equipment on consumer-oriented passenger vehicles, and there’s no shortage of aftermarket solutions, too. For example, if the system uses smartphone-style apps, those could deliver malware that then spreads to other, non-infotainment systems in the vehicle.  

 

Commercial vehicles such as tractor-trailers could be particularly attractive targets because of SAE J1939, the interface that’s the de facto standard for what’s known as controller area networks (CANs) inside these vehicles. SAE J1939 is an example of how standards—de facto or otherwise—can facilitate large-scale attacks on all of the vehicles that use them.

 

There are dozens of other possibilities. The common denominator is that when hackers identify a vulnerability in a piece of computer hardware or software, they now have a way to attack thousands or millions of those products at once. The same risk applies to vehicles.

 

For example, they could target a trucking company whose fleet has a lot of vehicles with a weakness they’ve figured out how to exploit. Maybe that attack uses the ransomware model: Lock the brakes on every single one of those trucks until the company pays up. That’s also an example of how attack vectors from the IT world could be ported to the vehicle world.

 

Question: In the IT world, software and hardware vendors use patches and updates to eliminate vulnerabilities. Is that an approach we’ll see in the vehicle world?

 

Prowell: Yes, but with a few big caveats. For example, a Hewlett Packard Enterprise study found that in enterprise IT, the top 10 exploits were more than one year old, and 68 percent were at least three years old. That’s because many IT departments don’t apply patches and updates in a timely manner. Often the delays are because they’re overloaded with so many projects. Sometimes it’s because they’re concerned that a patch or update will break something. It’s likely that we’ll see the same problems and delays when it comes to patching and updating telematics and other vehicular systems in a fleet.

 

And that’s assuming the patches and updates exist at all. A car or truck usually stays on the road for 10, 15 years and sometimes longer. That’s a time span where one or more of its vendors could decide to stop supporting those telematics and other systems because it’s no longer profitable to do so. Or some of those vendors could go out of business, orphaning those systems.

 

Those are just a couple of examples of how vehicles could become more vulnerable as they age. That’s going to be a major challenge for businesses and consumers that own them.

 

Question: How are you and your Oak Ridge National Laboratory colleagues working to improve vehicle cybersecurity?

 

Prowell: One example is the Trustworthy Vehicle Computing System (TVCS), which is creating an assessment framework and developing cybersecurity standards that automakers, their suppliers and others can apply. Some examples of TVCS projects are:

 

•       Vehicle-based proximity authentication to help thwart long-range attacks like the Jeep and Prius ones I mentioned earlier.
•       Scanning resilience, which involves detecting and blocking scans by hackers.
•       Electric vehicle security, such as using TrustZone technology to portect devices and infrastructure such as batteries, inverters and charging stations.