Connected cars becoming victims of marketeers

Senator Edward J. Markey has warned the US that new standards are needed to plug security and privacy gaps in our connected cars and trucks.
In a press release commenting on his report, released in February 2015, Markey said, “Drivers have come to rely on these new technologies but, unfortunately, the automakers haven’t done their part to protect us from cyber-attacks or privacy invasions. Even as we are more connected than ever in our cars and trucks, our technology systems and data security remain largely unprotected."
Based on his requests for information to 16 major automakers, he found:
· Nearly all vehicles on the market include wireless technologies that could pose vulnerabilities to hacking or privacy intrusions;
· Most automobile manufacturers were unaware of or unable to report on past hacking incidents;
· Security measures to prevent remote access to vehicle electronics are inconsistent and haphazard across the different manufacturers;
· Only two automobile manufacturers were able to describe any capabilities to diagnose or meaningfully respond to an infiltration in real time and most said they rely on technologies that cannot be used for this purpose at all.
Automakers and their suppliers generally disagree. Andrew Poliak, global director, business development for QNX Software Systems, says: "I disagree with what Senator Markey has said about the steps automakers have taken to secure connected cars. Automakers take this issue very seriously and I have seen first-hand the steps they take to secure their vehicles. Safety for passengers is their number-one priority and, as cars continue to evolve, so will the tools and technologies deployed to keep them safe and secure."
In other words, it's complicated.
Raj Paul, vice-president, automotive and emerging technologies for Lochbridge, notes that there have been no actual attacks against connected cars. There have been plenty of demonstration hacks, but these have taken place in academic settings and usually involve direct access to the OBD port.
There's a simple reason why we haven't seen real-world attacks: maybe it's just too soon for hackers to bother. Willie Horton robbed banks because that's where the money was but there's no money in automotive data… yet. Just as we didn't begin to see internet phishing and hacking until credit card and other financial information began to be transmitted online, crooks may not get interested in connected cars until, or if, people begin transacting in them or transmitting valuable data.
Damian Barnett, director, Elektrobit Automotive, says: "I don't think a lot of people today know whether or not that data is valuable." The potential for hacking depends on whether people find that data valuable and have a market for it. In addition to the value of the data, he says, hackers will consider the cost/benefit analysis: how much effort will they have to put into cracking a car versus how much benefit they can get.
(For more on the value of telematics data, read TU’s Striking Gold in Telematics Data.)
Remote hacks
Things did get hairier with the recent demonstration attacks against BMW ConnectedDrive and OnStar. Both of these were achieved without physical access to the car.
In the first case, researchers at the German Automobile Association (ADAC) were able to spoof a cellular base station and trick a BMW into unlocking its doors. In the second case, DARPA researchers exploited a buffer overflow vulnerability to reprogram the car's software to provide remote control of vehicle functions including braking – on US national TV, no less.
General Motors and BMW immediately took steps to cure the vulnerabilities, of course, but plugging holes after they're found isn't the best approach.
Of course, release first and patch later is the route that's been taken by every new technology, points out Mike Parris, head of the secure car division at SBD. He's not surprised that OEMs are focusing on what features and functions they can offer without necessarily thinking through all the security implications. "It's a bit harsh to be overly critical of the OEMs. On the other hand," Parris says. "It is kind of surprising that some of the mistakes being made are being made."
There are two main reasons why these mistakes might be made, according to Parris. First, in the absence of real-world attacks, there's not a strong motivation for automakers to focus on security. Second, there are no international standards for cybersecurity.
Parris thinks that vehicle-to-vehicle work in the United States and Europe could lead to usable security standards. He notes that NHTSA put out a request for information for a vehicle-to-vehicle (V2V) security credential management system last summer.
"In the absence of standards and real-world attacks, it would be impractical to make a completely secure car," Parris says, "but automakers should at least understand what the threats are and take a structured, risk-based decision on what you're going to protect against. It's fairly obvious to prioritize safety-related as opposed to privacy-related risks."
Weak points
Paul says that the CAN bus is an obvious weak point. It was never designed to handle the volume of internal traffic in modern cars. While automakers design around this vulnerability, he thinks that switching to Ethernet is the best strategy for both handling traffic among ECUs and other automotive hardware and also reducing vulnerabilities.
"Adoption on that is pretty slow, because the automotive ecosystem is complex," Paul said. But, if and when Ethernet is adopted: "A lot of the standard security solutions will come into play." The switch would allow automakers to follow the well-established playbook for enterprise security, which includes multiple layers of security and isolating critical information.
"Some of these fundamental security architectures that are in the enterprise could be used to design cars. It's not new, it's just that people don't realise that they need to learn from enterprise security," Paul says.
QNX is starting to see requests for information from OEMs that blend advanced safety features with infotainment, according to Poliak. The strategy should be to partition safety-critical features like instrument clusters or ADAS from open-source software and downloads. "That way, if you're downloading infotainment, it wouldn’t have any way to corrupt the processor," he says.
Who's responsible for security? "I'm a strong proponent of a healthy ecosystem where everyone has a role to play. If a Tier 1 provides parts to an OEM and will be part of the connected ecosystem, the Tier 1 has to have security in everything it designs and builds. It's not just an OEM problem," says Lochbridge's Paul. Still, at the end of the day, "…it's the OEM brand that builds and owns the car brand gets to make the final say."
That's great in theory but the practice of automotive design and manufacture can muddy the water, according to Mike Parris, head of the secure car division at SBD.
"Criminal groups attack implementations, they don't attack designs," Parris says. Even if a system has been designed to be secure, it may not have been implemented properly. It could be a simple error, he says, such as an individual who writes software who leaves a diagnostics back door to help in debugging and then forgets to close the back door before signing in the code.
Silicon chip manufacturers may include security in their chips, but the component manufacturer still needs to take advantage of those security features. In Parris' experience, only about half of component manufacturers do so. This could be because some chip security features lock the firmware, which component makers or OEMs may need to do.
Moreover, suppliers tend to make devices for more than one OEM. "They might have certain features in a product which not all the OEMs need. It's not uncommon for a function to exist in an ECU that the OEM doesn't know about," Parris said.
Once an OEM receives a component, it needs to test that it works reliably in all sorts of conditions; testing security probably comes way down the list. "It's easy to stand back from the automotive industry and sling the mud, but when you understand how these things are actually made and the time pressure and everything else, how much time delay do you put into testing something which isn't a real-world threat?"
Another problem, according to Parris, is that while individual elements of a software architecture or system may be secure, when elements are linked together, they become vulnerable. This is what happened in the BMW and OnStar demonstrations. While none of the vulnerabilities may have seemed significant on its own. "The clever bit was that people were able to link together a number of them, and, in doing so, the whole was greater than the sum of the parts," he said.
In all, he identified six vulnerabilities in BMW ConnectedDrive and three in GM OnStar and he found that some had been introduced at the design stage and some during implementation. He notes that there was no overlap between the two systems. In other words, OEMs can't simply check to make sure their own systems don't have these security issues. They may have still other ones.
Elektrobit's Barnett said suppliers have to proactively work with OEMs to understand how their components will be used and fit into the overall implementation. Even if the software it provides at one end of the vehicle communications chain is secure, Barnett said the company should not assume, "…nothing can happen to us. We would always assume anything can happen."
Third-party security assessments
Some companies, including SBD and Lochbridge, provide security assessments or other security services for OEMs. QNX is partnering with sister company Certicom to create full solutions for OEMs. The members of the Global Auto Alliance also provide onsite quality assurance teams to OEMs. The benefit, they say, is that a disinterested third party will provide an unbiased threat assessment, as well as bringing a fresh eye to the overall architecture.
In addition, Elektrobit's Barnett thinks OEMs should create new organisations within the company to take a holistic look at automotive systems. Testing, he notes tends to focus more on whether a feature or application works correctly. More attention needs to be paid, he says, to trying to break or crack features.
QNX sees this happening already. Says Poliak, "We've seen a couple OEMs start to have roles like head of cybersecurity, and almost all OEMs are looking at the vehicle as an entire ecosystem around it. The importance of security is bubbling up."