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 6/3/2020
Data Loss Spikes Under COVID-19 Lockdowns
Seth Rosenblatt, Contributing Writer,  5/28/2020
Abandoned Apps May Pose Security Risk to Mobile Devices
Robert Lemos, Contributing Writer,  5/29/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10548
PUBLISHED: 2020-06-04
rConfig 3.9.4 and previous versions has unauthenticated devices.inc.php SQL injection. Because, by default, nodes' passwords are stored in cleartext, this vulnerability leads to lateral movement, granting an attacker access to monitored network devices.
CVE-2020-10549
PUBLISHED: 2020-06-04
rConfig 3.9.4 and previous versions has unauthenticated snippets.inc.php SQL injection. Because, by default, nodes' passwords are stored in cleartext, this vulnerability leads to lateral movement, granting an attacker access to monitored network devices.
CVE-2020-10546
PUBLISHED: 2020-06-04
rConfig 3.9.4 and previous versions has unauthenticated compliancepolicies.inc.php SQL injection. Because, by default, nodes' passwords are stored in cleartext, this vulnerability leads to lateral movement, granting an attacker access to monitored network devices.
CVE-2020-10547
PUBLISHED: 2020-06-04
rConfig 3.9.4 and previous versions has unauthenticated compliancepolicyelements.inc.php SQL injection. Because, by default, nodes' passwords are stored in cleartext, this vulnerability leads to lateral movement, granting an attacker access to monitored network devices.
CVE-2020-11094
PUBLISHED: 2020-06-04
The October CMS debugbar plugin before version 3.1.0 contains a feature where it will log all requests (and all information pertaining to each request including session data) whenever it is enabled. This presents a problem if the plugin is ever enabled on a system that is open to untrusted users as ...