Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

3/6/2018
02:30 PM
James Plouffe
James Plouffe
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
0%
100%

Connected Cars Pose New Security Challenges

The auto industry should seize the opportunity and get in front of this issue.

Very few objects are as personal to their owners as their cars. But today's cars have grown beyond a form of self-expression and turned into our personal concierges, navigating the best routes, making our dinner reservations, and potentially reserving parking spots ahead of our arrival. But with all the advantages connected vehicles can bring to our lives, they can also potentially expose us to security risks.

Security risks for networked computers are nothing new, but connected cars present new challenges precisely because, although cars have long been largely computerized, they weren't networked. Many parts of cars — like the accelerator pedal or the turn signal — are designed to feel mechanical despite being run by tiny microprocessors that are connected through a network within the vehicle. Even so, vehicle software security hasn't really been a concern because cars have always been isolated and self-contained entities. Now that they connect to the Internet, they expose a new attack surface. How can we secure these connected vehicles that are now accessing our networks?

It's too early to tell how vehicle connectivity may impact an enterprise and it may seem absurd to think about a car as an enterprise network endpoint, but some luxury vehicle brands already have office productivity tools in-dash. Using the car as a workstation will only increase in popularity as autonomous driving replaces manual driving. In addition to the in-dash email, cars are also providing Wi-Fi hotspots and interfaces like Apple iOS CarPlay and Google Android Auto, which make our cars look and act more like our phones, raising the same kinds of concerns that are present with mobile devices in personal life and for the enterprise.

Autonomous driving isn't limited to making knowledge workers' windshield time more productive. Logistics companies, for example, will benefit tremendously from autonomous vehicles, but imagine an attacker compromising and shutting down those vehicles: the results would be disastrous not only to the logistics company but to all of the businesses that rely on them as a vendor. The same could be true for any business that relies heavily on connected vehicles.

Cautionary Tales
There are already cautionary tales about networked vehicles from other industries. Airlines, for example, were surprised when a security researcher claimed to have used an in-flight entertainment system to access the flight-control computers and modify a plane's behavior. This was possible because there was insufficient segmentation between the networks supporting the critical functions and the networks supporting ancillary services. While accounts differ about the nature and severity of the incident, it’s clear that ubiquitous and unrestricted connectivity creates unintended risk.

Of course, conducting such an attack requires the attacker to be on the plane. But that wouldn't necessarily be the case if there was an Internet connection available. To improve vehicle security, we must segment out the subsystems, separating entertainment and concierge services from the systems responsible for vehicle operation. This will ensure that neither is a gateway to the others and they don't interact or affect one another. As intravehicle networks evolve and mature, even more segmentation may become desirable, but minimally it is necessary for two segments: one for systems and communications critical to the function of the vehicle, and one for "everything else."

The telecom industry — with its stringent requirements for uptime and wide variety of services — has done a relatively good job of designing networks that separate critical operations from noncritical ones, as well building in resilience and mechanisms that prevent network abuse. The automotive industry could borrow these segmented network security concepts for use in their own factories in which the cars are built, for example the mission-critical machines and the computers that operate them reside on one protected network, while systems supporting less important front-office functions, such as email and file servers, reside on separate networks.

It's unclear whether the automotive industry acknowledges this as a problem. If one out of 20 million produced cars malfunctions, that is statistically insignificant and may not be enough to drive major change. Ideally, auto companies would take their own initiative, benefiting from models established by organizations like state Bar Associations or The American Medical Association which prescribe requirements and standards of behavior for their membership. They could even create an industry-specific standards framework as the payment card industry did with the PCI Data Security Standard.

Ultimately, auto companies should treat this as a product safety feature in much the way that they do with seatbelts, air bags, and all the mechanical components of their product; they must ensure that they have clearly defined preventative and remedial maintenance procedures for the useful lifespan of their products.

While we are still a way off from hackers redirecting vehicles, or entering an enterprise network through a connected car, the technology is evolving and the infrastructure is forming to make these concerns a reality in the coming years. By taking cues from other industries that have navigated these channels, the auto industry has an opportunity to get ahead of the demand for security that is sure to come with innovation.

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

James Plouffe is a Lead Architect with MobileIron and a Technical Consultant for the hit series Mr. Robot. In his role as a member of the MobileIron Product and Ecosystem team, he is responsible for driving integrations with new technology partners, enhancing existing ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
3/8/2018 | 2:11:05 PM
Long history
Alas, automakers have a history of downplaying (and even ignoring) exploits and vulnerabilities in their cars (see, e.g., forbes.com/forbes/welcome/?toURL=https://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ ). Can't say as I particularly trust them.
Jon M. Kelley
50%
50%
Jon M. Kelley,
User Rank: Moderator
3/8/2018 | 11:38:24 AM
Re: Connected cars need extensive blackbox testing
Once Mobile Ransomware starts hitting connected cars, the U.S. government may get involved as it did with seatbelts and airbags.  Given history we may have decades of connected cars before government regulations force manufacturers to fix them.  Unfortunately for consumers, manufacturers have learned that remote software updates are very cost effective.  This will leave the connection available for others, as well as manufacturers, to try to turn it into a revenue stream. 
HamidK95001
50%
50%
HamidK95001,
User Rank: Author
3/6/2018 | 3:41:28 PM
Connected cars need extensive blackbox testing
A rapidly emerging trend is to apply extensive blackbox testing for connected cars and in particular fuzzing seems to be rather effctive in exposing hidden weaknesses. 
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15564
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be map...
CVE-2020-15565
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs....
CVE-2020-15566
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, o...
CVE-2020-15567
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes...
CVE-2020-15563
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM g...